AI engineering, c'est quoi vraiment ?

Les deux premiers articles de cette série ont posé un déplacement : l'IA accélère la production de code, et le métier glisse vers spécifier, vérifier, décider où l'humain valide. Reste à nommer ce que devient, concrètement, le travail. On l'entend partout : AI engineering, ingénierie de l'IA. Le mot laisse penser qu'il s'agit de mieux « parler » au modèle — de trouver le prompt parfait. C'est l'inverse. L'ingénierie IA commence là où le prompt s'arrête : il s'agit de construire des systèmes fiables autour de modèles qui, eux, ne le sont pas — parce qu'ils sont non déterministes et faillibles par nature.

Au-delà du prompt : une discipline, pas un talent d'invocation

Un modèle de langage ne renvoie pas une réponse : il renvoie une réponse plausible. C'est un point de départ, pas une garantie. Le profil « IA générative » du NIST le formule sans détour : ces systèmes produisent des confabulations — un « contenu énoncé avec assurance mais erroné ou faux » (familièrement, des hallucinations), et ce n'est pas un bug qu'on corrigera un jour, mais « un résultat naturel de la façon dont les modèles génératifs sont conçus ». La recherche académique confirme l'ampleur du phénomène : une revue de littérature de référence sur le sujet rappelle que « les grands modèles de langage sont sujets à l'hallucination, produisant un contenu plausible mais non factuel ».

Si le composant central est faillible par construction, la fiabilité ne peut pas venir de lui : elle doit venir de ce qu'on met autour. C'est exactement le sens de l'ingénierie IA. Le développeur ne devient pas un souffleur de prompts ; il devient l'ingénieur d'un système dont le modèle n'est qu'une pièce — une pièce puissante, mais qu'il faut cadrer, tester, borner et surveiller. Quatre disciplines s'articulent autour de lui (Fig. 1).

Les quatre piliers de l'ingénierie IA

Le premier pilier est le contexte. Un modèle ne sait que ce qu'on lui donne au moment de répondre : la qualité d'une sortie dépend d'abord de la qualité de l'information fournie — les bons documents, les bonnes données, les bonnes contraintes de rôle et de limites. Une grande partie du travail d'ingénierie consiste à assembler ce contexte de façon fiable et reproductible, bien avant de « rédiger un prompt ».

Le deuxième pilier est celui des évaluations — les evals. C'est là que l'ingénierie IA rompt le plus nettement avec le développement classique. Un test unitaire vérifie qu'une entrée donne exactement la sortie attendue : c'est binaire, reproductible. Mais une sortie de modèle est non déterministe — deux appels identiques peuvent différer, et « juste » n'est pas une égalité de chaînes de caractères. Évaluer, ici, c'est mesurer une qualité sur un échantillon représentatif, avec des critères explicites, et suivre cette mesure dans le temps. Le cadre de gestion des risques du NIST consacre à cela une fonction entière, MEASURE, dont l'objet est d'« analyser, évaluer, comparer et surveiller le risque IA » — et de vérifier que le comportement du système est « surveillé lorsqu'il est en production ». Sans evals, on ne sait pas si un changement a amélioré ou dégradé le système : on croit, on ne mesure pas.

Le troisième pilier, ce sont les garde-fous : valider ce qui entre, valider ce qui sort, borner ce que le système a le droit de faire. Les recommandations de sécurité OWASP pour les applications à base de LLM en donnent la grammaire. À l'entrée, l'injection de prompt est classée risque numéro un (LLM01) ; la parade passe par la contrainte du rôle du modèle et le filtrage des entrées. À la sortie, la règle est de traiter le modèle « comme n'importe quel autre utilisateur, en adoptant une approche “zéro confiance” » (LLM05) : une sortie n'est jamais transmise telle quelle à un système en aval sans validation. Et lorsque le modèle peut agir — appeler des outils, déclencher des opérations —, l'« agence excessive » (LLM06) impose le moindre privilège et « une validation humaine des actions à fort impact avant qu'elles ne soient entreprises ». Le garde-fou n'est pas une option : c'est du code, autour du modèle.

Le quatrième pilier est l'observabilité : journaliser les appels, tracer les décisions, mesurer le coût et détecter les régressions. On ne pilote pas ce qu'on ne voit pas. Ce n'est d'ailleurs pas qu'une bonne pratique : le règlement européen sur l'IA, à son article 12, exige que les systèmes à haut risque permettent « techniquement l'enregistrement automatique des événements (journaux) sur toute la durée de vie du système ». La traçabilité devient une obligation, et l'observabilité, la condition pour tenir la fiabilité dans le temps — pas seulement le jour de la mise en production.

Ce n'est pas du machine learning classique

Il faut lever une confusion fréquente : ingénierie IA n'est pas synonyme de machine learning (Fig. 2). Le ML classique consiste à fabriquer un modèle : collecter et étiqueter des données, entraîner, régler, optimiser une métrique d'apprentissage, livrer un modèle figé. C'est un métier de data science, centré sur le modèle lui-même. L'ingénierie IA part de l'autre bout : le modèle existe déjà — on l'appelle, souvent via une interface de modèle de fondation — et tout le travail consiste à construire un système fiable par-dessus. On n'entraîne pas, on orchestre.

Ce déplacement explique pourquoi les compétences qui comptent ne sont pas celles qu'on imagine. Savoir formuler une requête aide, mais reste marginal. Ce qui fait la différence, c'est de savoir spécifier précisément le comportement attendu, concevoir des évaluations qui capturent la qualité réelle, câbler des garde-fous qui tiennent, et instrumenter le système pour voir ce qu'il fait. Autrement dit : de l'ingénierie de système, appliquée à un composant probabiliste.

Ce que cela change pour le développeur

Le pendant de tout cela, c'est une bonne nouvelle : la valeur du développeur ne se dissout pas dans l'IA, elle se déplace vers l'ingénierie du système qui la rend fiable. Écrire moins de lignes à la main, oui ; mais concevoir davantage — le contexte, les evals, les garde-fous, l'observabilité. Le modèle n'est qu'un composant, faillible et remplaçable ; le système qui l'entoure, lui, porte la responsabilité de ce qui est livré.

Ce cadre éclaire aussi le reste de la série. Comprendre pourquoi une sortie peut être plausible sans être fondée suppose de savoir comment un modèle de langage produit sa réponse. Et les garde-fous ne se posent pas de la même manière selon qu'on a affaire à un simple assistant ou à un agent qui exécute des actions — c'est là que le pilier « garde-fous » devient concret.

L'ingénierie IA n'est donc pas un vernis de vocabulaire sur le prompt : c'est le nom du travail réel quand le modèle devient un composant de production. Spécifier, évaluer, borner, surveiller — le métier ne disparaît pas, il monte d'un cran. Le prochain volet de cette série partira de là : si le développeur devient l'ingénieur de ces systèmes, quelles compétences faut-il cultiver pour l'être vraiment ?