LLM‑First ou Code‑First ? Où l’intelligence doit‑elle se placer dans l’IA de production

Comment décider ce que le modèle doit gérer, ce que votre code doit gérer, et comment les connecter.

Il y a quelques années, l’architecture d’une application d’IA ressemblait à : envoyer une invite à un grand modèle de langage → obtenir une réponse → l’afficher à l’utilisateur. Ce n’est plus l’histoire complète de nos jours. On demande aux modèles d’interpréter l’intention, de récupérer des informations, de choisir des outils, d’appeler des API, d’élaborer des plans et d’exécuter des flux de travail multi‑étapes.

Ce changement a divisé le domaine en deux – LLM‑First ou Code‑First

Dans une architecture LLM‑first, le modèle occupe le centre et décide de la suite. Il lit la requête, choisit un outil, détermine l’ordre des opérations, vérifie les résultats intermédiaires et change de cap lorsque cela est nécessaire.

Dans une architecture code‑first, le logiciel/le code reste responsable du séquençage, des règles métier, de la validation, des autorisations et de l’exécution. Le LLM, ici, est comme un spécialiste que le code invoque lorsqu’une compréhension ou une génération de langage est requise.

Les gens aiment débattre de ce qui est meilleur. Je pense que c’est le mauvais argument. La meilleure question est de savoir où chaque type d’intelligence doit se placer. Les systèmes de production les plus robustes que j’ai vus sont rarement purement l’un ou l’autre. Ils combinent raisonnement probabiliste et contrôle déterministe, et le font délibérément.

Pourquoi le LLM‑First est‑il si séduisant

Les logiciels traditionnels fonctionnent parfaitement lorsque vous pouvez expliciter les exigences. Par exemple, un utilisateur choisit un produit, saisit un montant et soumet un paiement. Vous définissez les états autorisés, les règles de validation, les conditions d’erreur et la séquence de transaction dans le code. C’est fait.

Le langage naturel ne coopère pas ainsi. Imaginez un utilisateur tapant : « Trouve les transactions qui semblent inhabituelles, explique ce qui s’est passé et indique‑moi ce que je devrais enquêter en premier ».

Il n’existe aucun chemin fixe pour cette requête. Le système doit alors déterminer ce que signifie « inhabituel », identifier les données pertinentes, éventuellement appeler plusieurs outils, évaluer la réponse et rédiger une explication exploitable par une personne. Aucune équipe d’ingénieurs ni aucune solution sans code ne pourra anticiper chaque formulation et chaque combinaison de demandes à l’avance.

C’est l’endroit où un LLM joue un rôle essentiel, en agissant comme une couche de raisonnement flexible entre le langage humain et vos services déterministes. C’est aussi la raison pour laquelle les agents suscitent tant d’attention. les directives d’architecture IA agentique de Google Cloud décrit un agent comme une application où un modèle d’IA agit comme moteur de raisonnement, tandis que les outils lui permettent d’atteindre des systèmes externes et des données.

d’Anthropic Building Effective AI Agents directivesfait une distinction à laquelle je reviens sans cesse. Dans un flux de travail, les modèles et les outils suivent des chemins que votre code définit. Dans un agent, le LLM dirige son propre processus et décide comment utiliser ses outils. Les mêmes directives recommandent de commencer par l’architecture la plus simple qui résout le problème, plutôt que d’ajouter une complexité agentique par réflexe. J’insisterais deux fois sur ce conseil.

Les limites de « Laisser le modèle décider »

Un modèle peut raisonner sur ce qui doit se produire. Le raisonnement n’est pas équivalent à l’application d’une règle.

Par exemple, prenons un flux de travail financier. Un LLM peut être excellent pour comprendre « envoyer le même montant que j’ai envoyé le mois dernier au même fournisseur ». Mais devrait‑il également décider si le virement est autorisé, calculer les limites réglementaires, vérifier la propriété du compte, contourner une politique de sécurité et exécuter la transaction ?

Probablement pas. Ces tâches sont déterministes, testables, auditables et exécutables, et c’est exactement ce en quoi les logiciels traditionnels excellent. Le risque augmente lorsque les modèles accèdent aux outils. les directives de sécurité d’IA générative d’OWASP signale une autonomie excessive comme un risque important : donner à un système basé sur un LLM plus de fonctionnalités, d’autorisations ou d’autonomie que son rôle ne le nécessite. Un résultat de modèle étrange ou manipulé est une chose lorsqu’il ne produit que du texte. C’est bien plus problématique lorsque le modèle peut agir dans le monde réel.

Tout cela ne signifie pas que les modèles ne doivent jamais agir. Cela signifie que l’autonomie du modèle doit être encadrée par une autorité déterministe.

Le code‑first reste important

Avec la rapidité des évolutions de l’IA, il est facile de penser que l’ingénierie conventionnelle est dépassée. Je soutiens le contraire. L’IA rend les bons systèmes déterministes encore plus importants, pas moins.

Le code reste le bon choix chaque fois qu’une tâche exige une répétabilité exacte. L’authentification est l’exemple le plus simple. Un modèle ne doit pas « raisonner » sur le fait qu’une personne possède des privilèges d’administrateur. Votre application doit interroger un système d’identité et de gestion des accès autoritaire. Il en va de même pour les calculs monétaires, les vérifications de droits, la validation des données, les contraintes réglementaires, les limites de transaction, la validation de schéma, et tout ce qui est irréversible. Tout cela nécessite des contrats explicites, pas des suppositions.

Cela s’aligne avec une réflexion plus large sur la gouvernance. Le NIST AI Risk Management Framework demande aux organisations de gérer les risques liés à l’IA à travers la conception, le développement, le déploiement et l’utilisation. Son compagnon Generative AI Profile ajoute que les systèmes génératifs peuvent nécessiter une surveillance supplémentaire, une documentation, une révision et des contrôles, selon le risque encouru.

Je trouve donc utile de diviser chaque décision de conception en deux questions :

Que doit se passer ?

et

Qu’est‑ce qui est autorisé à se produire ?

Un LLM peut souvent aider pour le premier. Les systèmes déterministes devraient généralement prendre en charge le second.

Le modèle hybride : raison probabiliste, exécution déterministe

Pour la plupart des applications d’entreprise, la réponse pratique est hybride. Le LLM agit comme couche d’interprétation et de raisonnement. Les services déterministes servent de couche d’exécution et d’application.

Voici un exemple. Supposons qu’un assistant IA aide les développeurs à créer des environnements temporaires de test d’API, et qu’un développeur tape : « Donne‑moi un bac à sable pour le flux d’onboarding client. »

Le LLM peut interpréter cela, déterminer quel flux de travail est probablement visé, lire la documentation et suggérer quelles API sont probablement pertinentes. Mais la création réelle de l’environnement ne doit pas dépendre d’un texte généré librement. Le code peut vérifier que les API demandées existent, valider leurs contrats, contrôler l’autorisation, appliquer les limites de ressources, générer une configuration approuvée et lancer le déploiement.

La répartition approximative ressemble à ceci :

• Le LLM : comprendre, raisonner, classer, proposer, résumer.
• Le code : valider, autoriser, calculer, persister, appliquer, exécuter.

Chaque côté effectue le travail pour lequel il est le plus performant, et aucun n’est sollicité pour simuler les forces de l’autre.

Les limites comptent davantage à mesure que les agents gagnent en puissance

Cette séparation devient plus importante à mesure que nous passons des assistants aux agents. Un assistant qui donne une mauvaise réponse gêne quelqu’un. Un agent disposant d’un accès en écriture à la production peut provoquer un désordre bien plus important.

La solution ne consiste pas forcément à éliminer l’autonomie. Il s’agit d’ajouter de l’autonomie progressivement tout en conservant des points de contrôle explicites. les directives de Google sur les systèmes multi‑agents recommande d’associer un comportement IA dynamique à des contrôles de sécurité déterministes, à l’observabilité, à une autonomie clairement définie et à une supervision humaine pour les scénarios critiques pour l’entreprise.

L’approbation humaine peut également être intégrée directement au flux de travail plutôt que d’être un filet de sécurité informel.Microsoft’s agent framework documentation, par exemple, prend en charge les appels d’outils qui s’interrompent jusqu’à ce qu’une personne approuve explicitement l’opération demandée.

Le principe est simple : plus les conséquences d’une action sont importantes, plus les contrôles déterministes qui l’entourent doivent être stricts.

Cinq questions à se poser avant de confier une tâche à un LLM

Lorsque je décide si un composant doit être LLM‑first ou code‑first, je passe en revue les points suivants :

1. La tâche a‑t‑elle une réponse objectivement correcte ? Si oui, privilégiez le code déterministe. Les calculs fiscaux, les autorisations et la validation de schéma ne doivent pas changer parce qu’un modèle les interprète différemment aujourd’hui.
2. Implique‑t‑elle un langage ambigu ou des informations non structurées ? Si c’est le cas, un LLM peut apporter une réelle valeur ajoutée.
3. Que se passe‑t‑il si le modèle se trompe ? L’architecture adaptée à un résumé de réunion est très différente de celle requise pour initier un paiement.
4. La sortie peut‑elle être validée de façon indépendante ? Les plans générés par un LLM deviennent beaucoup plus sûrs lorsque des règles déterministes peuvent vérifier l’action résultante avant son exécution.
5. Ce besoin nécessite‑t‑il réellement un agent ? Si vous connaissez déjà les étapes, un flux de travail classique avec quelques appels ciblés au LLM est généralement plus simple, moins coûteux, plus facile à tester et à exploiter.

Cette dernière question mérite une attention particulière. Les agents sont puissants précisément parce qu’ils peuvent gérer des situations où vous ne pouvez pas prévoir chaque étape. Mais si vous pouvez prévoir les étapes, les transformer en un problème de raisonnement ouvert ajoute souvent de la variabilité sans ajouter d’intelligence.

La fiabilité est une propriété architecturale, pas un prompt

De nombreuses équipes commencent par essayer d’améliorer la fiabilité presque exclusivement via l’ingénierie des prompts. Les prompts comptent, mais ils ne peuvent pas porter toute la charge.

Un système de production doit supposer que la sortie du modèle sera parfois incomplète, malformée, inattendue ou simplement erronée. La liste OWASP Top 10 pour les applications LLM répertorie des risques tels que injection de prompt et gestion inappropriée des sorties, ce qui renforce une habitude clé : traiter la sortie du modèle comme une entrée non fiable pour les systèmes en aval, et non comme des instructions à exécuter automatiquement.

Cela change la question que vous posez. Au lieu de « Comment écrire une consigne qui fait toujours que le modèle respecte la règle ? », demandez « Comment concevoir le système de façon que la règle ne puisse pas être enfreinte même lorsque le modèle commet une erreur ? »

C’est un problème d’architecture logicielle, pas un problème de consigne. Une consigne peut indiquer à un agent de ne pas effectuer une action non autorisée. Un service d’autorisation peut réellement l’arrêter. Ces deux contrôles ne sont pas équivalents.

Au‑delà du débat : systèmes orientés intention

En réfléchissant à tout cela, je suis arrivé à la conviction que le débat LLM‑first versus code‑first pointe vers une troisième idée : intent‑first architecture.

Dans un système orienté intention, l’application commence par comprendre ce que l’utilisateur essaie d’accomplir. C’est là que le LLM est le plus précieux, car les gens sont rarement précis sur ce qu’ils veulent. À partir de là, le système convertit progressivement cette imprécision en opérations structurées et déterministes.

Une requête telle que « Aidez‑moi à résoudre le problème de paiement du client » pourrait se transformer en pipeline : comprendre l’intention, récupérer la transaction, identifier la raison de l’échec, recommander une solution, demander une approbation, exécuter l’opération approuvée.

Certaines de ces étapes bénéficient du raisonnement d’un modèle de langage. D’autres devraient être des services fixes. L’architecture n’est pas définie par la victoire de l’IA ou du code. Elle est définie par les endroits où l’incertitude est acceptable.

En résumé

À mesure que les modèles s’améliorent, il sera tentant de leur confier le contrôle de parties de plus en plus importantes de la pile. Parfois, ce sera la bonne décision. Dans d’autres systèmes, la conception la plus sophistiquée sera celle qui donne délibérément au modèle moins d’autorité.

L’ingénierie de l’IA en production, en fin de compte, consiste à placer l’intelligence à la bonne frontière. Utilisez les modèles de langage là où l’interprétation, le raisonnement, la synthèse et l’adaptation créent de la valeur. Utilisez des logiciels déterministes là où la cohérence, l’autorisation, la précision et l’application sont essentielles. Puis connectez les deux via des interfaces étroites, observables et bien testées.

L’avenir de l’IA d’entreprise ne sera probablement pas purement LLM‑first ou purement code‑first. C’est le LLM là où l’incertitude nécessite de l’intelligence, et le code là où la certitude nécessite du contrôle.

Cette distinction peut compter bien plus que le choix du modèle.