gemini-3.8-flash en pratique : 5 scénarios d'application textuelle à forte valeur et points clés de mise en œuvre

Pourquoi partir des scénarios plutôt que des paramètres du modèle

Lors du choix d'un modèle textuel, la première réaction de nombreuses équipes est de comparer une à une les lignes d'un tableau de spécifications : longueur de contexte, vitesse d'inférence, scores aux benchmarks. Mais ce qui détermine réellement si un projet peut être mis en production n'est souvent pas ces chiffres, mais plutôt si le scénario métier a été ramené à un contrat d'entrée-sortie clair.

Avec un même modèle, l'utiliser pour « convertir un e-mail client en champs structurés » et pour « rédiger un texte créatif ouvert » présente des difficultés d'ingénierie totalement différentes. Le premier cas exige seulement de la stabilité et de la vérifiabilité ; le second nécessite un contrôle du style et une sélection humaine. L'ordre correct est donc :

1. Décrire d'abord clairement la tâche métier : quelle forme de texte constitue l'entrée, à qui la sortie est destinée, et par quel système en aval elle sera consommée.
2. Définir ensuite le contrat d'entrée-sortie : champs, format, longueur maximale, mode d'expression des valeurs manquantes, ce qui est renvoyé en cas d'échec.
3. Choisir le modèle en dernier : utiliser le contrat pour faire tourner le jeu d'évaluation, plutôt que de deviner les performances à partir d'un tableau de spécifications.

Placer le scénario au premier plan présente un autre avantage concret : une fois le contrat fixé, le modèle devient un détail d'implémentation interchangeable. Aujourd'hui, on fait fonctionner le flux avec gemini-3.8-flash ; demain, on change de modèle ou on ajuste les stratégies de nouvelle tentative et de dégradation, et le code métier n'a presque pas besoin d'être modifié — à condition que tous vos appels soient regroupés dans une couche d'interface unifiée, et non dispersés dans les différents modules métier.

Tous les exemples de cet article passent par l'interface compatible Chat Completions : les requêtes sont envoyées à https://api.hiapi.ai/v1/chat/completions, avec prise en charge de la sortie en flux. Côté entrée, seuls le texte et l'image sont acceptés, la limite de contexte est de 1 048 576 tokens, la sortie maximale par appel est de 65 536 tokens ; l'intensité de raisonnement se transmet via reasoning_effort avec les valeurs low / medium / high, le niveau précis étant à choisir selon l'évaluation de la tâche réelle. Il faut préciser d'emblée que cette interface ne fournit actuellement pas d'appel d'outils (function calling), de recherche web, de computer use ni de sortie structurée (mode JSON) ; toutes les contraintes de format doivent donc être écrites dans le prompt et vérifiées dans votre code.

Chaque modèle dispose de deux circuits : le circuit standard utilise directement le nom du modèle (par exemple gemini-3.8-flash), le circuit Vertex ajoute @vertex après le nom du modèle (par exemple gemini-3.8-flash@vertex). Les noms de modèles et la facturation diffèrent entre les deux circuits ; ci-dessous, les exemples utilisent uniformément le circuit standard.

from openai import OpenAI

client = OpenAI(base_url="https://api.hiapi.ai/v1", api_key="YOUR_KEY")

resp = client.chat.completions.create(
    model="gemini-3.8-flash",
    messages=[{"role": "user", "content": "把这封客户邮件里的联系人、公司、意图抽成 JSON"}],
    reasoning_effort="medium",
    stream=True,
)

Les 5 scénarios ci-dessous couvrent la majorité des besoins textuels : extraction structurée, génération de contenu en masse, classification et étiquetage, résumé et réécriture, questions-réponses conversationnelles. Leur point commun est un périmètre de tâche clair et des résultats évaluables, ce qui correspond précisément aux domaines où les modèles textuels produisent le plus facilement une valeur stable.

Scénario 1 : extraction structurée à partir de texte non structuré

C'est l'un des scénarios au meilleur rapport valeur/effort. L'entrée est un texte libre — e-mail, paragraphe de contrat, description de ticket, note de formulaire — et la sortie est un JSON directement consommable par les systèmes en aval.

La définition des champs doit permettre de juger de l'absence de valeur

La cause la plus fréquente d'échec des tâches d'extraction n'est pas seulement la capacité du modèle : une définition floue des champs est tout aussi déterminante. Pour chaque champ, trois choses doivent être explicitées : le type, le caractère obligatoire ou non, et le mode d'expression en cas d'absence. Par exemple, lorsqu'un montant ne peut pas être extrait, renvoyer null plutôt qu'une chaîne vide, afin que l'aval puisse distinguer « cette information n'existe pas » de « une valeur vide a été extraite ».

{
  "contact_name": "string|null",
  "company": "string|null",
  "intent": "purchase|support|other",
  "deadline": "YYYY-MM-DD|null",
  "confidence_notes": "string"
}

Fournir des énumérations dans le contrat plutôt que laisser le modèle improviser

Pour tout champ pouvant être énuméré, lister systématiquement toutes les valeurs légales dans le prompt. La classification à ensemble ouvert est le pire ennemi de la stabilité de l'extraction : le modèle inventera une étiquette qui semble raisonnable, alors qu'elle n'existe pas dans le dictionnaire en aval.

La sortie doit passer par une couche de validation

Ne supposez pas que la sortie du modèle est nécessairement un JSON valide. Cette interface ne fournit pas de sortie structurée (mode JSON) ; le format de sortie ne peut être garanti que par le prompt, la couche de validation n'est donc pas optionnelle. Échec d'analyse, type de champ incorrect, valeur hors énumération : tout doit être intercepté dans le code, avec nouvelle tentative ou passage à un traitement manuel. Une approche simple consiste à enchaîner : analyse → validation de type → validation des règles métier (par exemple, une date ne peut pas être antérieure à aujourd'hui) → insertion en base seulement si tout est validé.

La gestion des valeurs manquantes doit suivre une stratégie

En cas d'absence d'un champ obligatoire, ne laissez pas le flux passer silencieusement. Vous pouvez choisir de réessayer automatiquement une fois (en insistant dans le prompt sur la nécessité d'extraire ce champ au mieux) ; si l'absence persiste, marquez l'enregistrement comme à compléter manuellement et conservez la raison. C'est bien moins coûteux que de laisser des données sales entrer dans la base principale.

Scénario 2 : génération de contenu en masse et textes modèles

Textes marketing, titres et descriptions de produits, paragraphes de pages d'atterrissage SEO : ces tâches se caractérisent par un volume élevé, une structure similaire, des exigences unitaires modérées mais une sensibilité à la cohérence de style.

Fixer la structure avec un modèle, remplir les différences avec des variables

Ne traitez pas l'ensemble du prompt comme un texte libre que l'on modifie sans cesse. Décomposez le prompt en deux couches :

• Couche fixe : rôle, ton, mots interdits, plage de longueur, format de sortie. Cette partie doit rester stable sur le long terme.
• Couche variable : nom du produit, arguments de vente, audience cible, canal. Cette partie est remplacée à chaque appel.

Ainsi, vous ne maintenez qu'un seul modèle, et les problèmes de qualité de génération peuvent être attribués soit au modèle, soit aux variables.

La longueur de sortie doit être contrainte explicitement

La facturation au token signifie que plus la sortie est longue, plus le coût est élevé, et cet écart est amplifié dans les scénarios en masse. Indiquez une plage explicite dans le prompt (par exemple « pas plus de 80 caractères ») et fixez côté code une limite de sortie comme garde-fou. N'attendez pas du modèle qu'il juge lui-même « que c'est suffisant ».

Les tâches en masse doivent être traitées par lots et dédupliquées

Soumettre des milliers d'éléments d'un coup expose facilement à des limitations de débit et à des expirations. Il est recommandé de découper selon une taille de lot fixe, de ne relancer que les éléments en échec pour chaque lot, et d'enregistrer un hachage de chaque entrée pour dédupliquer — une génération répétée gaspille des tokens et pollue la bibliothèque de contenus par des textes redondants.

Prévoyez une étape de sélection manuelle en aval

L'usage réel de la génération en masse consiste généralement à « générer N variantes, en sélectionner M manuellement ». Générer plusieurs variantes par appel et laisser un humain faire la sélection finale est plus rentable que de viser la perfection sur un seul texte, et correspond mieux aux habitudes des équipes de contenu.

Scénario 3 : classification, étiquetage et reconnaissance d'intention

Les tâches de classification semblent les plus simples, mais pour être mises en production de manière stable, la difficulté réside dans le système d'étiquettes plutôt que dans le modèle.

L'ensemble d'étiquettes doit être fermé et défini

Chaque étiquette est accompagnée d'une définition en une phrase, ainsi que d'exemples positifs et négatifs. Les étiquettes doivent autant que possible être mutuellement exclusives : si « consultation après-vente » et « retour/échange » se recouvrent largement, le choix du modèle devient aléatoire et l'évaluation ne permet plus de localiser le problème.

Les échantillons limites comptent plus que les échantillons ordinaires

Lors de la construction du jeu d'évaluation, concentrez vos efforts sur les cas limites : une phrase qui ressemble à deux catégories à la fois, qui ne contient qu'un demi-mot-clé, qui a un ton ironique, ou qui mélange des informations hors sujet. Le modèle ne se trompe presque jamais sur les échantillons ordinaires ; ce sont les échantillons limites qui provoquent les incidents en production.

Demandez au modèle de produire une information de confiance

Une pratique utile consiste à demander au modèle, en plus de l'étiquette attribuée, de fournir un jugement « appartient-il à l'une des catégories ci-dessus » ainsi qu'une brève justification. Le champ de justification n'est pas stocké en base métier, mais il est extrêmement utile pour diagnostiquer les erreurs de classification.

Router les cas à faible confiance vers un traitement humain

Ne visez pas une classification entièrement automatique. Fixez une stratégie : si l'étiquette principale est claire, enregistrement automatique en base ; si le modèle indique « incertain » ou si plusieurs candidats sont retenus, passage dans une file de relecture humaine. Les résultats de la relecture humaine peuvent alimenter de nouveaux échantillons d'évaluation, formant ainsi une boucle fermée.

Conserver un historique de l'évolution du système d'étiquettes

Une fois mis en production, l'ensemble d'étiquettes est sans cesse ajusté par les équipes métier. Conservez une version à chaque modification et enregistrez dans les données « avec quelle version de l'ensemble d'étiquettes cet élément a été étiqueté », sinon les données historiques ne seront pas comparables.

Scénario 4 : résumé de textes longs et réécriture de style

Le résumé et la réécriture ont en commun une entrée longue et une sortie courte, ce qui les rend naturellement adaptés à un modèle facturé au token, mais aussi particulièrement exposés au problème « semble correct, mais détails erronés ».

Les entrées longues doivent être découpées puis fusionnées

La limite de contexte est de 1 048 576 tokens, un document unique peut généralement être traité en une seule fois ; mais pour un ensemble de plusieurs documents ou lorsqu'il faut citer de nombreuses preuves, il convient de découper d'abord selon les frontières sémantiques (chapitres, paragraphes, lignes vides), de générer un résumé local bloc par bloc, puis de fusionner les résumés locaux en un résumé global. Conserver les informations de titre comme contexte de chaque bloc lors du découpage améliore sensiblement la qualité de la fusion.

Précisez le type de résumé souhaité

« Extractif » et « génératif » sont deux choses différentes. Le métier veut-il « conserver tous les chiffres et conclusions clés » ou « une lecture fluide » ? Le premier cas doit exiger du modèle qu'il cite autant que possible les formulations originales sans ajouter de faits ; le second peut être assoupli, mais il faut accepter un risque de déviation plus élevé.

La réécriture doit être accompagnée de contraintes vérifiables

La réécriture de style glisse facilement vers « la création libre ». Précisez les exigences : lecteur cible, ton, conservation ou non des termes techniques, plage de longueur, structure de paragraphes à conserver. Plus les contraintes sont précises, moins il y a de retouches.

La validation de cohérence est indispensable

Chiffres, dates, noms de personnes et noms propres sont les contenus les plus facilement altérés lors de la réécriture. Avant la mise en production, il faut au minimum une étape de validation automatique : extraire du texte original les entités clés et les chiffres, puis vérifier qu'ils apparaissent tels quels dans la sortie. Si le taux de correspondance n'est pas atteint, renvoyer pour réécriture ou passer à un traitement manuel.

Fixer une limite de longueur de sortie

Il est fréquent qu'un résumé s'allonge de manière incontrôlée. Outre la longueur indiquée dans le prompt, fixez également une limite de sortie au niveau de la requête, afin d'éviter que certains documents longs ne fassent grimper le coût unitaire.

Scénario 5 : questions-réponses conversationnelles et assistant métier

Les applications de questions-réponses sont les plus souvent sous-estimées : une démo se lance en trois minutes, mais pour fournir un service externe en tant qu'assistant métier, il faut tout un ensemble de gestion des limites.

L'organisation du contexte détermine la qualité des réponses

Ce que l'on met dans une requête est plus déterminant que la manière d'écrire le prompt. La structure typique est : rôle et règles du système, documents de contexte métier (extraits récupérés par pertinence), dernières N tours de conversation, question du tour courant. Les extraits doivent indiquer leur source et il faut indiquer clairement au modèle « répondre uniquement à partir des documents fournis ».

Le refus de répondre est une fonctionnalité, pas un défaut

Il faut concevoir explicitement un chemin de refus : lorsque la réponse ne figure pas dans les documents, que la question dépasse le périmètre métier ou qu'elle implique une opération sensible, le modèle doit fournir une formulation de repli fixe et orienter l'utilisateur vers un canal humain. Les formulations de refus doivent être inscrites dans le prompt système, et non laissées à l'improvisation du modèle.

L'état multi-tours réside dans votre code

Ne demandez pas au modèle de « tout mémoriser ». L'état de la session, l'identité de l'utilisateur, le numéro de commande déjà confirmé et autres informations déterministes doivent être maintenus par le système métier et injectés à chaque tour de requête ; le modèle se charge uniquement de formuler le langage. Ainsi, la conversation est reproductible et auditable.

Contrôler la longueur du contexte injecté à chaque tour

Plus la conversation est longue, plus l'historique transporté à chaque tour est important, et plus le coût par tour augmente. La méthode consiste à conserver les derniers tours en texte intégral et à compresser les tours plus anciens en quelques phrases clés de résumé. C'est l'une des principales variables de coût d'une application fonctionnant sur le long terme.

Prévoir un garde-fou distinct pour les actions exécutables

Si l'assistant déclenche des actions telles que des remboursements, des modifications de commande ou des envois de messages, la sortie du modèle ne peut servir que de suggestion ; l'exécution réelle doit passer par une validation des paramètres et un contrôle des permissions, avec confirmation humaine si nécessaire. Un modèle textuel ne doit pas disposer directement de droits d'écriture.

Contrôle des coûts et des performances sous facturation au token

La facturation au token signifie que le coût est presque entièrement déterminé par « longueur d'entrée + longueur de sortie ». Les actions de maîtrise des coûts peuvent essentiellement être rattachées à ces deux côtés.

Côté entrée : d'abord réduire, ensuite optimiser

• Ne transmettre que le nécessaire : insérer un document entier dans le prompt est le gaspillage le plus courant. Effectuez d'abord un filtrage de paragraphes ou une recherche, et ne transmettez que les extraits pertinents.
• Supprimer les textes de gabarit : pieds de page, avertissements, signatures répétées n'apportent rien au résultat mais sont facturés quand même.
• Contrôler le nombre de tours d'historique : l'historique d'une application conversationnelle doit être compressé par résumé, et non ajouté indéfiniment.
• Le prompt lui-même doit être concis : un prompt système maintenu sur le long terme a tendance à s'allonger ; révisez-le régulièrement et supprimez les exemples redondants.

Côté sortie : fixer des limites et utiliser des formats courts

La limite de sortie est le garde-fou de coût le plus direct ; la sortie maximale par appel de 65 536 tokens est la limite de l'interface, et le côté métier doit fixer une limite plus petite selon les besoins. En outre, demander dans le prompt au modèle de répondre avec un JSON compact (l'interface ne fournit pas de mode JSON, une validation manuelle est nécessaire) raccourcit généralement sensiblement la sortie ; demander « d'abord la conclusion, puis une phrase de justification » est également bien moins coûteux qu'une longue explication.

Remplacer les appels répétés par du cache

Appeler plusieurs fois avec la même entrée est un pur gaspillage. Pour les tâches déterministes (classification, extraction), mettez en cache les résultats en utilisant le hachage de l'entrée comme clé ; pour les tâches génératives, vous pouvez mettre en cache les extraits de documents récupérés plutôt que le texte final.

Regrouper les requêtes par lots

Pour les tâches sur texte court, plusieurs entrées peuvent être fusionnées dans un seul appel, en demandant au modèle de les traiter une par une dans l'ordre. Cela réduit le nombre de requêtes et le coût du prompt système répété, mais attention : l'échec d'une seule entrée affecte tout le lot, il faut donc analyser entrée par entrée et conserver la possibilité de réessayer.

Regarder les résultats et les coûts ensemble

Ne regardez pas seulement le coût d'un appel unitaire, mais « le coût total pour accomplir une action métier » : y compris le nombre de nouvelles tentatives, la proportion de relecture humaine, les retouches en aval. Une configuration peu chère mais nécessitant beaucoup de retouches est souvent plus coûteuse qu'une configuration stable au prix unitaire plus élevé. Seul un jeu d'évaluation fixe, enregistrant à la fois la précision et la consommation de tokens, permet un véritable arbitrage.

Plusieurs niveaux de choix et tarifs sous la même interface

• gemini-4-carbon : le modèle le plus puissant de la série Gemini 4, destiné aux tâches multi-étapes et de longue durée les plus complexes. Circuit standard 1,00 / 0,05 / 5,00, circuit @vertex 1,64 / 0,09 / 8,20.
• gemini-4-argon : adapté à la plupart des tâches d'ingénierie logicielle et de travail intellectuel, avec un équilibre entre capacité et coût. Circuit standard 1,00 / 0,05 / 5,00, circuit @vertex 1,64 / 0,09 / 8,20.
• gemini-3.8-flash : rapide et bon marché, adapté aux tâches à forte concurrence et à faible latence. Circuit standard 0,19 / 0,02 / 0,92, circuit @vertex 0,62 / 0,07 / 3,08.

Les prix sont en dollars par million de tokens, dans l'ordre : entrée / entrée en cache / sortie. Lors du choix, considérez ensemble la complexité de la tâche, les besoins en contexte, l'intensité de raisonnement et le coût : pour les tâches à forte concurrence, à faible latence et à faible exigence de raisonnement, privilégiez gemini-3.8-flash ; pour les tâches complexes multi-étapes et de longue durée, envisagez plutôt gemini-4-carbon ou gemini-4-argon.

Validation et conception de repli indispensables avant la mise en production

L'incertitude des sorties du modèle ne disparaît pas avec la mise en production ; elle devient un incident en l'absence de mécanisme de repli. Passer en revue cette liste de contrôle avant la mise en production permet d'écarter la plupart des problèmes.

1. Construire un jeu d'évaluation fixe

Prélevez des échantillons dans les données métier réelles, couvrant les cas typiques et les cas limites, avec pour chacun la sortie attendue annotée. Ce jeu d'évaluation doit être conservé avec versioning ; à chaque modification de prompt, changement de modèle ou ajustement de paramètres, exécutez-le et comparez précision et consommation de tokens. Sans jeu d'évaluation, il n'existe pas de phrase « les résultats se sont améliorés ».

2. Définir des critères de validation quantifiables

Ne validez pas à l'impression que « ça a l'air d'aller ». Fixez des indicateurs pour chaque scénario : pour l'extraction, la précision des champs et le taux de succès d'analyse ; pour la classification, la précision et la proportion de faible confiance ; pour le résumé, le taux de conservation des entités clés ; pour les questions-réponses, le taux de refus corrects et le taux d'intervention humaine. Les critères doivent être confirmés par l'équipe métier avant le développement.

3. Concevoir les chemins d'échec

• Échec d'analyse : réessayer une fois ; en cas d'échec persistant, placer dans une file à traiter, ne pas supprimer silencieusement.
• Expiration et limitation de débit : réessayer avec un recul exponentiel, et fixer une durée totale limite pour éviter l'accumulation de requêtes.
• Stratégie de dégradation : si le modèle principal est indisponible, existe-t-il un modèle de secours ou un repli par règles ? Il faut s'accorder à l'avance avec l'équipe métier sur l'acceptabilité de la différence de qualité après dégradation.
• Idempotence : le traitement répété d'une même requête métier ne doit pas produire de résultats en double.

4. Les chaînes critiques doivent faire l'objet d'une relecture humaine

Pour toute action dont la sortie du modèle affecte directement les droits ou les fonds de l'utilisateur, une relecture humaine ou une validation forte est nécessaire. Le modèle apporte l'efficacité, l'humain prend la décision finale ; ne renversez pas cette répartition.

5. Mettre en place un échantillonnage et une surveillance en ligne

Après la mise en production, continuez à prélever un échantillon proportionnel pour une relecture humaine, et enregistrez la tendance de la précision, la distribution des types d'échec, la consommation de tokens par requête. En cas d'anomalie, il faut pouvoir identifier rapidement si les données ont changé, si le prompt a été modifié ou si le comportement du modèle a dérivé.

6. Regrouper les appels dans une couche d'interface unifiée

Si les appels au modèle sont dispersés dans le code métier, il est impossible de faire ce qui précède. Une fois les appels regroupés dans une couche d'accès unifiée, le changement de modèle, l'ajustement des paramètres, les nouvelles tentatives et la dégradation peuvent être gérés en un seul endroit, et le côté métier ne fait face qu'à un contrat d'entrée-sortie stable. Cela rend aussi peu coûteux le fait de « comparer différents modèles avec le même jeu d'évaluation ».

Scénarios bien délimités, contrat d'abord, replis complets : c'est à ces conditions que les modèles textuels entrent véritablement dans les processus de production, et ne restent pas au stade de la démonstration.