Amazon Nova 2 Lite : ce qu’il faut vérifier lors d’une migration depuis Nova 1 lorsque le contexte atteint un million de jetons

Nova 2 Lite modifie le contrat d’intégration, pas seulement le nom du modèle

Amazon Nova 2 Lite est un modèle propriétaire disponible par l’intermédiaire de services AWS gérés. Son identifiant de base déclaré est `amazon.nova-2-lite-v1:0`. Sa fiche officielle indique une disponibilité à partir du 2 décembre 2025, une fenêtre de contexte pouvant atteindre un million de jetons et une sortie maximale déclarée de 64 000 jetons. Elle précise aussi que sa fin de vie ne surviendra pas avant le 2 décembre 2026 et prévoit une période minimale de maintenance héritée. Ces informations définissent des limites publiées du service, non un résultat garanti pour une charge de travail donnée.

Le qualificatif « Lite » ne permet pas d’en déduire que l’intégration sera simple, que la latence sera faible, que le coût par tâche sera inférieur ou que le comportement équivaudra à celui de Nova 1 Lite, Pro ou Premier. Il ne prouve pas davantage qu’un prompt, un schéma de sortie ou une automatisation existante conservera sa qualité après le changement de modèle. Une migration responsable doit traiter le modèle, l’API retenue, le profil d’inférence et la configuration de raisonnement comme des éléments d’un contrat à tester de nouveau.

Un contexte étendu peut modifier la conception d’une application. Il peut réduire le besoin de segmenter certains documents ou historiques, mais il ne supprime ni la nécessité de sélectionner les informations pertinentes, ni les limitations de permissions, ni le contrôle des données sensibles, ni la mesure des résultats. Un contexte de grande taille n’implique pas non plus que chaque partie du contenu aura le même poids dans la réponse ou que le modèle donnera des réponses factuellement exactes. Il s’agit de propriétés distinctes : capacité d’entrée, comportement de récupération au sein du contexte, exactitude et utilité opérationnelle.

La différence importante n’est donc pas seulement quantitative. En adoptant Nova 2 Lite, une équipe doit décider quelle modalité d’invocation elle utilisera, quelles entrées elle autorisera, si elle activera le raisonnement étendu, comment elle recevra et exécutera les demandes d’outils, et quel chemin d’inférence est compatible avec ses obligations de résidence des données. Chaque décision exige des éléments de preuve obtenus dans son propre environnement.

Inventaire du contrat : identifiant, modalités et limites à fixer avant les essais

Le premier livrable de migration devrait être un inventaire versionné. Il doit contenir l’identifiant du modèle, la région ou le profil d’inférence sélectionné, l’API d’invocation, les types de contenu autorisés par l’application et les limites que l’équipe appliquera avant d’appeler le service. La fiche de Nova 2 Lite déclare des entrées texte, image et vidéo. Le traitement des documents, les tailles exactes de fichiers, les combinaisons de blocs de contenu et la disponibilité effective doivent être vérifiés par rapport à la documentation API en vigueur et au moyen de requêtes de test.

La fenêtre d’un million de jetons mérite une lecture précise. Il s’agit d’une capacité maximale de contexte déclarée, et non d’une invitation à toujours envoyer le maximum. Une application peut rencontrer des limites pratiques dues à la composition de la requête, à la sortie demandée, à ses propres contraintes de mémoire, aux temps réseau ou à ses objectifs de latence. Elle doit aussi enregistrer le nombre de jetons entrants et sortants par opération : sans cette télémétrie, elle ne pourra pas identifier les régressions lorsque la taille des documents ou le comportement du modèle évoluent.

La sortie maximale déclarée de 64 000 jetons élargit également la surface de risque. Une sortie longue peut dépasser les limites de passerelles, de tampons, de files d’attente, d’interfaces utilisateur ou de validateurs en aval. Si le produit nécessite du JSON ou un autre format structuré, il ne suffit pas de constater que le modèle produit une réponse longue : il faut vérifier que le résultat peut être reçu en entier, validé, rejeté de manière sûre, puis réparé ou réessayé selon une politique explicite.

Il est utile de dissocier les limites du fournisseur des limites internes. Une organisation peut, par exemple, imposer un maximum de contexte inférieur afin de maîtriser la latence et le coût, un maximum de sortie adapté à une interface donnée, et un seuil de taille spécifique pour le contenu multimodal. Ces contraintes doivent apparaître dans la configuration et dans les tests, et non relever seulement d’une connaissance informelle de l’équipe.

Converse et Invoke : l’abstraction retenue conditionne la portabilité

La documentation d’Amazon Nova présente Converse comme une interface cohérente pour interagir avec les modèles et décrit Invoke comme une voie utilisant un format natif non portable. La conséquence pratique est claire : ce choix ne doit pas être fait sur le seul critère de la commodité initiale. Converse peut réduire les différences d’intégration lorsqu’une application doit fonctionner avec une interface commune, tandis qu’Invoke peut exiger que le client connaisse et maintienne un format propre au modèle.

Cela ne rend pas une interface systématiquement supérieure à l’autre. Une équipe doit vérifier que l’API choisie prend en charge les modalités, configurations et champs de réponse dont elle a besoin. Lorsqu’un format natif est utilisé, les tests doivent couvrir la sérialisation exacte de la requête, l’analyse de chaque bloc de réponse, les motifs d’arrêt et les erreurs. Lorsqu’une interface cohérente est utilisée, il faut aussi vérifier que son abstraction ne masque pas des options nécessaires et ne modifie pas la sémantique attendue par le produit.

La limite de temps mérite une revue d’architecture. AWS avertit que les requêtes d’inférence Nova peuvent nécessiter des délais d’attente allant jusqu’à 60 minutes et que le client doit les ajuster. Cela affecte les SDK, équilibreurs de charge, proxys, workers, limites d’exécution des fonctions et expérience utilisateur. Augmenter simplement un délai d’attente peut accroître les ressources retenues et ne résout ni l’annulation, ni les nouvelles tentatives, ni la déduplication.

Toute opération longue doit être encadrée par une politique explicite : quel composant peut l’annuler, comment l’annulation se propage, ce qui est enregistré si le client se déconnecte, quand elle peut être relancée et comment éviter l’exécution double d’une action externe. Ces décisions sont particulièrement importantes si la conversation peut déclencher des outils ou si la réponse suivante alimente un système automatisé.

Raisonnement étendu : configurer, mesurer et ne pas le confondre avec une explication complète

Nova 2 propose un raisonnement étendu au moyen de `reasoningConfig`. La documentation décrit les niveaux de budget `low`, `medium` et `high`. Activer cette fonction ne revient pas à ajouter une explication lisible et complète de l’obtention d’une réponse. La réponse peut comporter des blocs `reasoningContent`, mais AWS indique que le contenu de raisonnement est renvoyé sous forme expurgée. Ces blocs ne doivent donc pas être considérés comme un journal exhaustif des décisions ni comme une preuve suffisante pour un audit métier.

Le raisonnement étendu doit être évalué comme une variante de configuration indépendante. Un jeu de tests approprié compare, pour chaque tâche, le mode sans raisonnement et chaque budget que le produit envisage d’autoriser. Il doit relever le taux de réussite selon une grille définie, la validité de la sortie structurée, la durée totale, l’utilisation des jetons disponible dans la télémétrie, la fréquence des nouvelles tentatives et les résultats de sécurité. Le choix d’un budget doit répondre à un objectif mesuré, et non à l’hypothèse qu’un niveau plus élevé améliore tous les cas.

La traçabilité est également en jeu. Enregistrer la configuration demandée, l’identifiant de modèle, l’API et le profil d’inférence permet de reproduire une classe d’incident. Toutefois, ces journaux ne remplacent pas l’observation des entrées, des sorties, des décisions de l’application et des résultats des outils autorisés. Lorsque les données contiennent des informations personnelles ou confidentielles, la journalisation doit appliquer les mêmes politiques de minimisation, d’accès et de conservation que le reste du système.

Aucun élément de la documentation fournie ne permet d’affirmer que le raisonnement étendu garantit des réponses plus justes, plus sûres ou plus rapides. La décision raisonnable consiste à en limiter l’usage aux tâches pour lesquelles l’évaluation interne montre une amélioration suffisante au regard de ses effets sur la durée et l’exploitation.

Function calling : le modèle propose ; l’application autorise et exécute

La documentation de Nova 2 décrit le function calling comme un flux dans lequel le client définit des outils à l’aide de JSON Schema. Lorsque le modèle demande un outil, la réponse contient un bloc `toolUse` et un motif d’arrêt `tool_use`. La responsabilité de l’exécution de l’outil incombe explicitement au client, qui doit renvoyer le résultat au modèle s’il souhaite poursuivre l’interaction. Cette répartition est essentielle : une demande générée par le modèle n’est pas une autorisation d’effectuer une action externe.

La couche applicative doit valider le nom de l’outil et ses arguments selon un contrat strict, vérifier l’identité et les permissions de l’utilisateur, appliquer des limites de fréquence et de périmètre, exécuter avec des identifiants à privilège minimal et transformer les erreurs en résultat contrôlé. Elle doit aussi décider du traitement des arguments ambigus, des ressources inexistantes, des réponses contenant des données sensibles, des erreurs transitoires et des opérations non idempotentes. Un JSON Schema améliore la définition de l’interface, mais ne remplace ni les contrôles d’autorisation ni la validation sémantique.

La proposition de migration mentionne des outils intégrés, tels que le grounding web ou un interpréteur de code. Les sources vérifiées fournies pour cet article documentent le flux de function calling, mais ne permettent pas d’établir ici quels outils intégrés sont disponibles pour Nova 2 Lite, dans quelles conditions, sur quelles voies d’invocation ou dans quelles régions, ni comment ils traitent les données et les permissions. Cette incertitude doit être levée à partir d’une documentation spécifique à jour avant de concevoir un flux qui en dépend.

Les tests des outils doivent inclure la réussite comme l’échec. Il ne suffit pas de montrer que le modèle sélectionne une fonction avec une requête simple. Il faut tester les arguments valides et invalides, les permissions refusées, les délais d’attente, l’indisponibilité du service externe, les résultats partiels, la répétition d’appels et le rejet d’une action potentiellement dommageable. L’application doit conserver la maîtrise de l’effet externe, même si le modèle insiste sur un appel.

Migrer depuis Nova 1 : remplacer un identifiant ne démontre pas l’équivalence

Les sources fournies ne contiennent pas de matrice officielle permettant d’affirmer une équivalence fonctionnelle directe entre Nova 2 Lite et Nova 1 Lite, Pro ou Premier. Il n’est donc pas rigoureux de promettre que le remplacement de l’identifiant préservera la qualité, les formats, la sélection d’outils, la latence ou le comportement multimodal. La migration doit être définie comme une substitution soumise à évaluation, non comme une mise à jour transparente.

Le point de départ consiste à figer une référence du système actuel. Pour chaque flux, l’équipe devrait conserver des entrées représentatives autorisées, la configuration de génération, les prompts système et utilisateur, les outils disponibles, les réponses attendues ou grilles de revue, la durée et le taux d’échec. Elle peut ensuite exécuter le même ensemble sur Nova 2 Lite, en distinguant les résultats par API, budget de raisonnement et profil d’inférence. Sans cette séparation, une régression peut être attribuée à tort au modèle alors qu’elle provient de la voie d’invocation ou d’une modification du prompt.

Les cas longs sont indispensables si le contexte étendu motive le changement. Ils doivent inclure des informations pertinentes réparties dans le contenu, des éléments non pertinents, des contradictions délibérées et les limites internes de l’application. Les cas multimodaux doivent évaluer chaque modalité réellement utilisée par le produit et vérifier que les mécanismes de chargement, de conversion et d’observabilité fonctionnent. Les sorties structurées exigent une validation automatique et une revue des échecs ; l’apparence d’un JSON correct ne démontre pas que ses valeurs sont adéquates.

La décision de déploiement peut être progressive. Une équipe peut conserver le modèle précédent pour les flux qui n’ont pas atteint les seuils, limiter Nova 2 Lite à des tâches observables et réversibles, ou désactiver le raisonnement et les outils jusqu’à la fin des essais. Cette prudence n’est pas un jugement négatif sur le modèle : elle évite de confondre les capacités déclarées avec des résultats démontrés dans un système particulier.

Régions, profils d’inférence et résidence : transformer une politique en preuve

La disponibilité régionale et la résidence des données ne doivent pas être déduites du nom de la région depuis laquelle une requête est envoyée. Amazon Bedrock distingue l’inférence dans une région, l’inférence interrégionale via des profils géographiques et l’inférence interrégionale via des profils globaux. La documentation AWS précise qu’un profil géographique traite les requêtes au sein de la géographie définie, tandis qu’un profil global peut les traiter dans toute région commerciale prise en charge.

Cela impose de considérer le profil d’inférence comme un paramètre de conformité, et non comme un détail de performance. Avant d’activer Nova 2 Lite, l’organisation doit consulter la matrice de disponibilité à jour par modèle et par région, identifier le chemin retenu par sa configuration et le confronter à ses règles contractuelles, réglementaires et de classification des données. La disponibilité évolue dans le temps ; une conclusion tirée pendant un test ne doit pas remplacer un contrôle des changements.

AWS documente que CloudTrail enregistre `additionalEventData.inferenceRegion`. Ce champ peut fournir une preuve opérationnelle du lieu de traitement utilisé par une requête. Néanmoins, l’équipe de conformité doit déterminer quelle période de conservation, quelle couverture de journaux et quels contrôles complémentaires sont nécessaires. Un journal utile au diagnostic ne certifie pas à lui seul que l’ensemble de l’architecture respecte une obligation sectorielle.

Le test doit être réalisé avec l’identité, le compte, la région et le profil d’inférence prévus pour la production. Il doit vérifier que les événements attendus sont générés, que le champ est conservé et qu’une modification non autorisée de profil peut être détectée. Si la politique interdit une voie globale, cette interdiction doit être concrétisée dans les contrôles de configuration et les permissions, plutôt que de reposer sur une convention de nommage.

Critères d’acceptation et limites des conclusions possibles

Une batterie minimale d’acceptation devrait couvrir les contextes courts et longs, les entrées multimodales réellement utilisées par le produit, les réponses structurées valides et invalides, les demandes d’outils correctes et mal formées, les refus de permissions, les pannes d’outils, l’annulation, les nouvelles tentatives et la répétition d’une même requête. Elle doit mesurer les percentiles de latence sur l’ensemble de la chaîne, y compris les composants intermédiaires, car le délai d’attente du client ne décrit pas à lui seul l’expérience réelle.

Les seuils doivent être définis avant l’observation des résultats afin d’éviter d’approuver une migration sur une impression subjective. Ils peuvent inclure un taux minimal de respect d’une grille, un maximum de sorties non conformes, une proportion maximale d’opérations nécessitant une intervention humaine et une limite de durée par type de tâche. L’évaluation humaine reste nécessaire lorsque le résultat dépend du sens, de l’utilité ou d’un risque contextuel qui ne peut être réduit à une comparaison mécanique.

Après avoir réussi ces tests, il est raisonnable d’affirmer que Nova 2 Lite a satisfait aux critères définis pour les flux évalués, avec une configuration précise et pendant une période observée. Il n’est pas raisonnable d’extrapoler ce constat à tous les prompts, tous les documents, toutes les langues, toutes les régions ou tous les volumes de trafic. Il ne démontre pas non plus une exactitude factuelle générale, la conformité sectorielle, la fiabilité d’actions automatisées ou le coût réel par tâche à l’échelle.

L’exploitation ultérieure nécessite une observabilité et une voie de retour arrière. Versionner les prompts et les schémas, enregistrer le modèle et sa configuration, mesurer les erreurs et définir des signaux de repli permet de distinguer une variation ponctuelle d’une régression durable. Le but de la migration n’est pas de démontrer qu’un modèle est meilleur dans l’absolu, mais de décider de manière traçable pour quelles tâches, quelles données et quels contrôles son utilisation est acceptable.

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.