Claude Haiku 4.5 : exploiter une voie à faible latence après Haiku 3.5 sans confondre conservation minimale et continuité garantie

Le problème n'est pas de choisir un petit modèle : c'est de préserver un contrat opérationnel

Le retrait de Claude Haiku 3.5 impose d'examiner davantage que la qualité apparente des réponses. Anthropic documente que l'identifiant de Haiku 3.5 n'est plus disponible depuis le 19 février 2026 et recommande Claude Haiku 4.5 comme remplacement. Cette recommandation fait de Haiku 4.5 un candidat raisonnable à évaluer, mais elle ne démontre pas qu'il soit interchangeable dans une application donnée.

Pour une équipe qui classe des demandes, extrait des champs, assiste une personne en temps réel ou exécute des sous-agents à périmètre limité, le produit ne consomme pas uniquement un modèle. Il consomme une combinaison d'identifiant, de fournisseur d'accès, de région ou d'endpoint, de SDK, de paramètres de génération, de prompt système, d'outils, de validateur, de politique de tentatives et de budget de temps. Modifier l'un quelconque de ces éléments peut changer le résultat observé.

L'unité de migration doit donc être le flux complet. Un changement qui préserve la précision moyenne tout en augmentant le temps de mise en file ou la proportion de documents nécessitant une réparation de JSON peut dégrader le service. De même, une réponse plus rapide du modèle ne garantit pas une meilleure latence de bout en bout si le canal choisi, l'outil externe ou une nouvelle tentative consomme la marge disponible.

Cette analyse porte sur la capacité de Haiku 4.5 à maintenir une voie rapide contrôlable. Elle ne vise pas à établir sa supériorité sur un modèle de plus grande capacité ni à extrapoler des résultats de benchmarks à une charge de production. La preuve décisive pour cette décision provient de tests reproductibles menés par l'équipe sur son trafic, ses schémas et ses dépendances.

État du cycle de vie : une date minimale n'est pas une promesse ouverte

La documentation des dépréciations d'Anthropic répertorie `claude-haiku-4-5-20251001` comme actif dans l'API directe et indique que son retrait n'interviendra pas avant le 15 octobre 2026. Cette formulation est importante : elle fixe une limite minimale de conservation, et non une date de retrait confirmée ni une garantie de disponibilité au-delà de ce jour.

Par conséquent, à la date de référence du 22 septembre 2026, l'identifiant peut être considéré comme disponible d'après la documentation fournie, mais il doit être traité comme une dépendance dont l'horizon de révision est proche. Un système qui traduirait « pas avant » par « restera disponible » introduirait une hypothèse qui n'est pas étayée par cette source.

Google Cloud affiche également une date minimale de retrait au 15 octobre 2026 pour Claude Haiku 4.5 dans son catalogue de modèles partenaires. La coïncidence d'une date minimale entre canaux ne supprime pas la nécessité de consulter l'état propre à chaque intégration. L'identifiant exposé, les régions activées, la capacité et la politique de support relèvent du canal d'accès, pas seulement du modèle.

L'incertitude principale n'est pas sémantique : les sources fournies ne confirment pas une date finale de retrait pour Haiku 4.5. Elles n'apportent pas non plus de garantie de capacité pour chaque compte, région ou modalité d'invocation. Le plan doit donc envisager à la fois un avis formel de cycle de vie et une dégradation opérationnelle d'un canal avant même qu'un retrait soit annoncé.

La définition d'une voie rapide doit inclure la file, la validation et l'abandon

Une métrique de génération isolée est insuffisante. Pour des interactions qui affectent un écran, une automatisation synchrone ou une décision en ligne, il est préférable de mesurer depuis la réception de la requête par le service jusqu'au retour d'une réponse exploitable par l'application. Cet intervalle inclut la sérialisation, le réseau, l'attente en file, le premier octet ou premier token, la génération, les appels d'outils, la validation, la réparation et la livraison.

Le tableau de bord minimal doit distinguer la latence jusqu'au premier token de la latence totale. La première approche la capacité à commencer une réponse en streaming ; la seconde détermine le moment où l'utilisateur ou le processus peut agir. Les deux doivent être analysées par percentiles, au minimum p50, p95 et p99, et par type de charge. Une moyenne faible peut masquer une file de cas lents qui épuise les délais d'attente.

Il faut également mesurer la proportion de sorties acceptées au premier essai. Pour l'extraction structurée, le signal utile n'est pas que le modèle produise un texte qui ressemble à du JSON, mais que l'objet soit analysable, satisfasse le schéma et passe les règles métier. Pour les outils, le signal est que l'appel soit valide, autorisé, exécutable et que son résultat soit incorporé sans boucle ni effets dupliqués.

Attribuer l'incident est aussi important que le compter. Une hausse de durée peut provenir du modèle, du chemin réseau, d'une limite de débit, du SDK, d'un outil externe ou du validateur. Si les journaux ne conservent pas le canal, la région, la version demandée, la durée de chaque phase et le motif de la nouvelle tentative, l'organisation ne pourra pas déterminer ce qu'il faut revenir en arrière.

Tests de régression : évaluer des tâches, pas un score agrégé

L'évaluation doit utiliser un corpus figé et représentatif, complété par du trafic en miroir lorsque cela est sûr. Le corpus doit inclure des entrées courtes et longues, des cas fréquents et des limites connues, les langues pertinentes, des documents à structure irrégulière et des conditions qui activent des outils. Il est utile de le versionner avec le prompt, le schéma, le validateur et le code d'évaluation.

Pour la classification, mesurez la concordance avec une référence révisée ainsi que le coût des faux positifs et faux négatifs par catégorie. Pour l'extraction, mesurez les champs corrects, les omissions, les hallucinations de valeurs et l'acceptation complète du schéma. Pour les réponses brèves étayées, définissez quelles sources ou données d'entrée doivent apparaître et comment une affirmation non soutenue par ce contexte est pénalisée.

Les sous-agents exigent un traitement spécifique. Leur réussite ne se limite pas à une réponse finale plausible : elle comprend le nombre d'étapes, les invocations d'outils, le respect des permissions, l'arrêt une fois l'objectif atteint et l'absence de modifications dupliquées. Exécutez d'abord en mode sans effet ou contre des ressources de test. Ne laissez pas une comparaison de modèles écrire dans des systèmes de production.

Anthropic identifie Haiku 4.5 parmi les modèles conscients du contexte dans ses orientations de prompting. Cela peut être pertinent pour adapter les modèles de prompt et les variables, mais ne remplace pas la régression. La forme du prompt, les instructions de sortie et le comportement des outils restent des propriétés que l'équipe doit vérifier dans le flux effectivement implémenté.

Le canal transforme l'exploitation : API directe, Amazon Bedrock et Vertex AI

Il ne faut pas supposer que le nom commercial du modèle implique une interface identique. L'API directe d'Anthropic documente l'identifiant daté `claude-haiku-4-5-20251001`. Dans Amazon Bedrock, la documentation fournie décrit des identifiants d'inférence régionaux, géographiques et globaux, ainsi qu'une disponibilité par régions et endpoints. Cette distinction peut affecter le choix du chemin et l'observabilité que l'application doit conserver.

Dans Google Cloud, la fiche de Claude Haiku 4.5 utilise l'ID `claude-haiku-4-5`, liste les entrées texte, image et PDF, la sortie texte, les fonctions, le prompt caching, l'extended thinking et les prédictions par lots. Elle indique également les régions `us-east5`, `europe-west1` et un endpoint global. Ces capacités documentées ne doivent pas être interprétées comme une obligation de les activer ni comme une égalité de configuration avec l'API directe.

Le document Google Cloud relatif aux endpoints multirégion explique une différence opérationnelle importante : les endpoints globaux, multirégion et régionaux impliquent des choix différents concernant la résidence des données, le quota, la résilience et le profil de latence. Un test réalisé depuis un endpoint global ne répond donc pas, à lui seul, à ce qui se produira si le service de production requiert une région précise ou des contraintes de résidence.

La comparaison entre canaux doit couvrir l'authentification, les limites effectives, les formats de requête et de streaming, la traçabilité, la politique d'erreur et le support de retrait. La source Amazon Bedrock confirme l'existence de variantes d'identifiants et de chemins d'inférence ; elle ne suffit pas à affirmer les performances d'un compte donné. De même, les capacités énumérées par Google Cloud ne prouvent pas qu'une modalité soit activée dans toutes les organisations ni que son usage respecte le budget de latence.

Déploiement contrôlé : double exécution, canary et retour arrière explicite

Un changement de modèle doit commencer par un inventaire. Localisez les appels directs et indirects, y compris les workers, intégrations tierces, prompts embarqués, règles de repli et tâches par lots. Pour chaque consommateur, consignez l'objectif de service, la sortie attendue, le canal, la région, le responsable technique et le modèle alternatif. Sans cet inventaire, un retrait peut laisser des chemins oubliés qui n'apparaissent pas dans le test principal.

La double exécution sans effet permet de comparer les résultats sans modifier le système de référence. Envoyez un échantillon représentatif vers le flux actuel et vers Haiku 4.5, appliquez les mêmes validateurs et conservez des différences anonymisées lorsque les obligations relatives aux données le permettent. Pour les sous-agents, remplacez les outils d'écriture par des simulateurs ou exécutez-les dans des environnements isolés.

Ensuite, un canary doit exposer une fraction réduite et réversible du trafic réel. Les seuils de promotion et de retour arrière doivent être convenus avant le déploiement : par exemple, une dégradation des percentiles, une baisse de l'acceptation du schéma, une augmentation des erreurs d'outils ou une hausse des abandons. La valeur numérique de chaque seuil dépend du flux ; elle ne peut pas être déduite de la documentation d'un fournisseur.

Le fallback ne doit pas être une étiquette configurée mais jamais testée. Il doit disposer de capacité, de permissions, d'un modèle de prompt compatible, de limites connues et d'un chemin d'activation avec un responsable. Testez aussi bien la bascule manuelle que, si elle existe, la bascule automatisée. Mesurez le temps nécessaire à son activation et les requêtes qui restent en cours durant le changement.

Plan de sortie : découpler l'application d'un identifiant précis

La meilleure préparation à un changement de cycle de vie consiste en une frontière d'application stable. Le reste du produit devrait demander une opération — classer, extraire, répondre ou exécuter un outil autorisé — sans connaître l'identifiant précis du modèle. Un adaptateur peut traduire cette opération dans les formats de chaque canal, normaliser les événements de streaming et appliquer un validateur commun.

Ce découplage n'exige pas de prétendre que tous les modèles sont identiques. Le contrat doit exposer les différences qui comptent : modalités prises en charge, longueur et structure de sortie, politique d'outils, possibilité de streaming, délais maximaux et comportement en cas d'indisponibilité. Les capacités incompatibles doivent échouer explicitement ou déclencher une dégradation connue ; il ne faut pas les dissimuler derrière une conversion qui modifie la sémantique.

Conservez la preuve de chaque changement : version des prompts, corpus de test, résultats segmentés, configuration du canal, dates d'exécution, incidents et décision d'acceptation. Ce dossier permet de distinguer une régression ultérieure du modèle d'une modification du prompt, du SDK, du réseau ou du validateur. Il réduit également le délai de réaction si le fournisseur annonce un retrait ou si un endpoint cesse de respecter le budget opérationnel.

La conclusion est conditionnelle. Haiku 4.5 dispose d'une documentation qui le présente comme un remplacement de Haiku 3.5 et comme une option disponible dans les canaux examinés. Toutefois, seule une évaluation de bout en bout peut démontrer qu'il maintient une voie rapide pour une organisation donnée. La date minimale de conservation doit être utilisée comme échéance pour finir cette évaluation et répéter une sortie, non comme une raison de la repousser.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.