Chapitre 1 — La discipline de l'ingénierie IA

Premier billet de la tournée chapitre par chapitre de LLM Primer V : Construire des applications LLM réelles. Le chapitre qui affirme que la raison pour laquelle votre démo marche et pas votre système de production n'est pas un problème de modèle — c'est un problème d'ingénierie, et cette ingénierie a un nom.

Pourquoi ce chapitre existe

Toute équipe qui livre une fonctionnalité LLM découvre le même écart. La démo tourne bien sur les vingt entrées choisies par l'équipe ; le système de production tourne mal sur les vingt mille qu'il ne voit jamais. Le modèle n'a pas empiré. L'équipe est simplement sortie de la zone où une sortie plausible en un coup compte comme un succès, pour entrer dans la zone de la charge, de la dérive, des entrées adversariales et de clients payants dont l'indicateur de plainte ne pardonne pas. Le Chapitre 1 nomme cette zone et lui donne une discipline. L'ingénierie IA n'est ni la science qui entraîne le modèle, ni l'art d'écrire un prompt astucieux. C'est l'ingénierie qui construit un comportement système déterministe autour d'un cœur probabiliste. Le reste du livre parcourt les surfaces où cette discipline vit ; ce chapitre pose le cadre.

1.1 L'écart de fiabilité entre la démo et la production

Une démo et un système de production sont identiques dans le diagramme d'architecture. Ils diffèrent par la charge, par la distribution des entrées de la queue, par le budget de latence, par la pression sur le coût et par le mode de défaillance. La différence dominante est statistique : la démo tourne sur quelques dizaines d'entrées choisies à la main, tandis que la production tourne sur des millions au contact de la longue queue — les requêtes bizarrement formulées, en partie dans une autre langue, sans contexte, ou volontairement adversariales. La fiabilité est une question de queues, pas de moyennes. En superposition, le modèle lui-même est non déterministe — échantillonnage, équilibrage de charge côté fournisseur, mises à jour silencieuses du modèle s'empilent — et les défaillances sont discrètes. Une mauvaise réponse s'analyse proprement, satisfait chaque vérification de type que l'équipe a écrite, et atteint l'utilisateur sans alerte. L'observabilité classique, qui compte les HTTP 200, ne voit pas ce mode de défaillance. Le premier mouvement de l'équipe consiste à reconnaître que la répétabilité, la correction et le coût sont des propriétés d'ingénierie à construire, non des hypothèses à hériter de la pile classique.

1.2 L'enveloppe déterministe autour du cœur probabiliste

La réponse architecturale consiste à laisser le modèle probabiliste et à l'envelopper dans du logiciel classique. L'enveloppe possède la forme d'entrée, la forme de sortie, la validation, les nouvelles tentatives, les repli, le cache, l'observabilité et la comptabilité de coût. Vue de l'extérieur, elle présente une fonction déterministe — une requête entre, une réponse validée sort. Vue de l'intérieur, elle contient un composant probabiliste appelé avec un délai d'attente, un schéma et un plan de récupération pour le cas où le modèle renvoie n'importe quoi. L'enveloppe a quatre bandes : validation de l'entrée, préparation du prompt, exécution sous contrat, récupération et émission. Ce n'est qu'après avoir franchi les quatre que la réponse devient la sortie officielle de l'enveloppe. La tentation récurrente consiste à repousser de la logique à l'intérieur du modèle — « laissons le modèle vérifier sa propre réponse » — et chaque pas dans cette direction est un pas hors de la testabilité. La discipline consiste à garder le cœur probabiliste petit, bien défini, contenu, et à garder autant de comportement système que possible dans du code déterministe que l'équipe peut versionner et raisonner.

1.3 Les cinq piliers : fiabilité, qualité, performance, coût, évolution

Le Chapitre 1 parcourt cinq postures d'ingénierie qui reviennent dans tout système de production. La fiabilité vient de la redondance : nouvelles tentatives avec repli exponentiel, chaînes de repli qui vont d'un primaire bon marché à un secondaire plus fort puis à un défaut fondé sur des règles, abstraction multi-fournisseurs, et disjoncteurs qui empêchent un fournisseur en peine d'entraîner tout en cascade. La qualité vient de la validation, sur deux couches : la validation de schéma attrape les erreurs de forme, la validation de contenu — vérifications d'ancrage, planchers de confiance, contrôles de garde-fous — attrape les erreurs sémantiques qui passent le schéma. La performance vient du cache, sur trois couches : correspondance exacte, sémantique, préfixe de prompt. La maîtrise du coût vient de la mesure et de l'attribution, du routage du trafic vers le plus petit modèle qui suffit, de budgets par utilisateur et par requête qui empêchent une boucle d'agent de dépenser mille dollars en silence, et de l'économie de prompt. L'évolution vient des cinq boucles de rétroaction — journalisation, évaluation, traçage, retour humain, déploiement canari — reliées en un circuit où une trace de production devient un cas d'évaluation, une régression d'évaluation bloque un déploiement, et le système s'améliore mois après mois.

Ce que prépare le Chapitre 1

Le reste du livre, c'est l'enveloppe, couche par couche. Le Chapitre 2 entre à l'intérieur de l'appel de modèle lui-même — tri par palier de modèle, paramètres d'échantillonnage, prompts défensifs, sorties structurées. Le Chapitre 3 s'étend vers l'extérieur, jusqu'à la récupération, pour que le modèle dispose du bon contexte sur lequel raisonner. Le Chapitre 4 transforme l'enveloppe en un agent qui peut appeler des outils. Les Chapitres 5 et 6 ajoutent les rails d'évaluation et d'observabilité. Les Chapitres 7 et 8 ferment avec la sécurité et l'économie du service. Le cadrage du Chapitre 1 est ce qui rend chaque chapitre suivant lisible : chaque technique est soit un moyen de resserrer l'enveloppe, soit un moyen de rendre le cœur probabiliste plus facile à envelopper.

Prochaine étape — Chapitre 2 : Modèles de base et ingénierie de prompt. La couche à l'intérieur de l'enveloppe — sélection du modèle, échantillonnage, prompts et sorties structurées — traitée comme des surfaces d'ingénierie plutôt que comme un art.