Mon côté développeur aime le moment où quelques lignes de code obtiennent une réponse d’un grand modèle. Mon côté directeur TI arrive une seconde après : qui va soutenir ce service lundi matin? Un 200 OK prouve un appel, pas un produit.

Je placerais l’API derrière notre propre service. L’application authentifie la personne et transmet une tâche structurée. Le service vérifie les droits, récupère seulement le contexte autorisé, construit une consigne versionnée, appelle le fournisseur, valide la sortie et enregistre les métriques. La clé du fournisseur ne va jamais dans le navigateur.

client → API interne → auth/quotas → récupération contexte
                  → prompt versionné → file/worker → fournisseur LLM
                  ← validation/schéma ← réponse
                  → journal redigé + coût + feedback

Pour une classification, je demande un format limité :

{
  "categorie": "FACTURATION|LIVRAISON|AUTRE",
  "confiance": 0.0,
  "justification": "court extrait"
}

Le parseur refuse une catégorie inconnue, une réponse trop longue ou du texte hors schéma. La confiance déclarée par le modèle n’est pas une probabilité calibrée; une règle et un jeu de validation déterminent quels cas peuvent être automatiques. Les autres vont en revue.

Prévoir les pannes ordinaires

L’appel utilise un timeout et un identifiant. Pour une tâche asynchrone, une file durable permet la reprise. Sur une erreur 429 ou 5xx, le worker applique un délai exponentiel avec aléa. Après quelques essais, un circuit breaker ouvre et le processus revient à une méthode simple plutôt que bloquer tous les threads.

essai 1 → 2 s + aléa
essai 2 → 4 s + aléa
essai 3 → 8 s + aléa
échec durable → file de reprise ou traitement manuel

Un retry ne doit pas déclencher deux actions. La génération elle-même peut être répétée; l’envoi au client, la création de ticket ou la transaction utilise une clé d’idempotence et se fait après validation. Le résultat brut n’a pas le droit d’appeler directement un outil d’administration.

Le coût se calcule par tokens d’entrée et de sortie, plus recherche, stockage et soutien. Je fixe un maximum par requête et par équipe. Un contexte de 20 000 tokens répété 10 000 fois devient une facture et une latence; le découpage et la récupération limitent ce qui est utile. L’alerte se déclenche avant le budget, pas à la facture mensuelle.

Le jeu d’évaluation vit avec le code :

1. cas courants, limites et absence de réponse;
2. données multilingues et formats cassés;
3. instructions malveillantes dans les documents;
4. informations interdites au compte courant;
5. réponses factuellement fausses mais plausibles;
6. latence, coût et limite de débit;
7. changement de modèle et de prompt;
8. panne complète du fournisseur.

Chaque version de modèle et prompt passe ces tests avant promotion. L’observabilité conserve identifiant, temps, tokens, version, décision et erreur, mais rédige les données sensibles. Un échantillon de sorties approuvées alimente l’évaluation seulement après revue; je n’entraîne pas automatiquement sur tout feedback utilisateur.

La sécurité commence par la classification, l’identité et le moindre privilège. Le contenu récupéré est une donnée, pas une instruction; un texte disant « ignore les règles » ne peut pas modifier le système. Les secrets restent dans un coffre, les sorties sont encodées avant affichage et les fichiers sont analysés.

Je commencerais avec une tâche étroite et réversible, un petit groupe, un plafond de coût et une date d’arrêt. La pratique est de pouvoir désactiver le modèle tout en gardant le service métier. Louer l’intelligence réduit l’investissement en GPU; ça ne loue ni nos permissions, ni nos tests, ni notre responsabilité opérationnelle.