Dernière mise à jour le July 27, 2026, par l’équipe éditoriale. Initialement publié sur Towards AI.

Un guide pratique pour faire fonctionner l’IA dans de véritables opérations

À un moment donné, un LLM générera une sortie qui semblera correspondre exactement à ce qui était nécessaire. Les champs seront présents, la structure paraîtra propre et les valeurs sembleront plausibles. Puis cette sortie sera utilisée dans un workflow réel, et le processus échouera.

Le problème peut venir d’un type de données, d’un champ manquant ou d’une valeur techniquement exacte mais incorrecte dans le contexte opérationnel. Quelque part entre le LLM et le système censé consommer sa sortie, quelque chose ne correspondra pas.

Ce type d’échec n’est pas principalement un problème de modèle. C’est un problème d’architecture, et il continuera de se répéter tant qu’il ne sera pas traité comme tel.

Une grande partie des discussions autour de ce problème est écrite par des ingénieurs pour d’autres ingénieurs. Les solutions proposées portent souvent sur l’ajustement fin des modèles, l’optimisation des prompts et l’infrastructure de déploiement. Ce sont des outils légitimes, mais ce ne sont pas toujours ceux auxquels les personnes les plus souvent confrontées au problème ont accès.

Cette question concerne particulièrement les chefs de projet, les responsables des opérations et les profils techniques non ingénieurs qui ne construisent pas de produits d’IA, mais essaient de rendre l’IA utile dans les workflows opérationnels qu’ils gèrent déjà. Depuis cette position, les problèmes et les modes de défaillance apparaissent différemment. L’architecture qui fonctionne en pratique ressemble souvent très peu à ce que décrivent la plupart des tutoriels sur les LLM.

Ce que l’IA opérationnelle a mal compris

Le problème central n’a jamais été que les systèmes manquaient d’intelligence. C’est que l’on demandait à l’intelligence d’accomplir une tâche qui dépend de la cohérence.

Lorsque les LLM sont devenus largement disponibles, de nombreuses organisations ont formulé une hypothèse raisonnable : si les systèmes pouvaient comprendre le langage et raisonner dans la complexité, les problèmes opérationnels deviendraient naturellement plus faciles à résoudre. Ce qui a été moins clairement énoncé, c’est que de nombreux problèmes opérationnels ne sont pas des problèmes de raisonnement. Ce sont des problèmes de répétabilité.

Les opérations reposent sur un contrat simple : la même entrée doit produire la même sortie à chaque fois. Ce n’est pas un manque d’ambition ; c’est la finalité d’un système opérationnel. Lorsqu’un système commence à raisonner de manière créative pour décider s’il faut déclencher un remboursement ou mettre à jour un enregistrement, quelque chose de plus important que l’efficacité est en jeu. La confiance dans la sortie est perdue.

La mécanique compte. Les LLM sont fondamentalement non déterministes. Posez deux fois la même question, et le système peut renvoyer deux réponses différentes. Les deux réponses peuvent être correctes, mais elles ne seront pas nécessairement identiques. Pour un assistant conversationnel, cette variabilité est acceptable. Pour un système qui génère des payloads, de la logique d’automatisation ou des workflows réutilisables devant s’exécuter de manière fiable sur des centaines de cas, cette même variabilité n’est pas une bizarrerie sans conséquence. C’est une incompatibilité structurelle.

La plupart des démonstrations montrent comment construire un outil qui fonctionne de manière isolée : une entrée est soumise, et une sortie apparaît à l’écran avec une apparence correcte. Ce que ces démonstrations ne montrent souvent pas, c’est ce qui se passe lorsque cette sortie doit être transmise à un autre système, par exemple une base de données, un endpoint d’API ou un processus en aval qui attend des noms de champs, des types de données et une structure exacts.

Une fois qu’une sortie de LLM entre dans un véritable écosystème de données, elle n’est plus jugée selon son apparence correcte. Elle est jugée selon son exactitude stricte. Ce sont des standards entièrement différents.

Un processus dans lequel une entrée non structurée alimente un LLM, qui produit ensuite une sortie non structurée destinée à un autre système, n’est pas un pipeline fiable. C’est une chaîne d’hypothèses qui attend le moment où l’une d’elles cessera d’être vraie.

Pourquoi l’automatisation pure ne suffit pas non plus

Si les LLM sont trop imprévisibles pour le travail opérationnel, l’alternative évidente consiste à revenir aux systèmes qui existaient avant eux : règles explicites, logique définie et sorties prévisibles. En théorie, un workflow soigneusement conçu devrait tenir.

Il tient, mais seulement jusqu’à ce que la réalité change.

Les systèmes fondés sur des règles capturent le monde tel qu’il existait au moment de leur conception. Le monde ne reste pas immobile.

Le format d’entrée attendu par un système est généralement celui que quelqu’un a accepté de fournir lors d’un trimestre précédent. Les noms de champs, la structure des données et la séquence des opérations ont tous été conçus autour d’une version de la réalité qui peut déjà être légèrement dépassée au moment où l’automatisation est mise en production. Lorsque cette réalité évolue, comme elle le fait inévitablement, le système ne s’adapte pas. Il casse. Parfois de façon visible ; parfois silencieusement, ce qui est pire.

Le second problème est le coût de la correction. Chaque cas limite qui sort des règles initiales exige une décision humaine, suivie d’une mise à jour de règle, de tests et d’un déploiement. Multiplié par l’entropie naturelle de tout environnement opérationnel réel, le fardeau de maintenance peut devenir le travail lui-même. À ce stade, l’organisation ne se contente plus d’exécuter un processus. Elle exécute un processus pour gérer le processus.

Ce qui se perd, c’est le jugement qui appartenait auparavant à la personne effectuant le travail manuellement. Il ne s’agit pas d’intelligence au sens ambitieux du terme. Il s’agit de la capacité pratique à regarder quelque chose de légèrement inattendu et à savoir quoi en faire.

C’est précisément l’écart que ni l’automatisation pure ni une approche fondée uniquement sur les LLM ne comblent à elles seules.

Le modèle d’architecture hybride

La solution n’est pas nécessairement un meilleur LLM. C’est une frontière plus nette.

Une fois qu’il est clair que les LLM et les systèmes déterministes échouent pour des raisons opposées, l’architecture concerne moins le choix d’une technologie que la répartition des responsabilités. La question n’est plus simplement de savoir quel outil utiliser. Elle devient : quelle couche du problème chaque outil est-il le mieux placé pour traiter ?

Dans les contextes opérationnels, les LLM sont utiles pour une tâche spécifique : convertir l’ambiguïté en structure. Ils peuvent prendre une entrée désordonnée, incohérente ou ouverte et produire une sortie propre et normalisée sur laquelle un système en aval peut agir. C’est une fonction précieuse, mais ce n’est pas tout le travail.

Les systèmes déterministes sont utiles pour l’exécution. À partir d’une entrée propre et structurée, ils effectuent la même opération de la même manière à chaque fois. Ils ne raisonnent pas, n’interprètent pas et ne varient pas. Cette prévisibilité n’est pas une faiblesse. C’est ce qui rend ces systèmes fiables à grande échelle.

Le modèle hybride place chaque couche là où elle doit être. L’ambiguïté est résolue avant d’atteindre la couche d’exécution. L’exécution se fait ensuite sans interprétation. La frontière entre ces deux couches n’est pas un détail technique mineur. C’est la décision de conception centrale.

Cette frontière modifie aussi la manière dont les données circulent dans le système. La sortie du LLM ne doit pas être transmise directement à l’exécution. Elle doit d’abord être validée. Selon le contexte opérationnel, cette validation peut inclure des contrôles de schéma, l’application de contraintes, des seuils de confiance ou d’autres critères. Si la sortie ne satisfait pas à ces exigences, elle ne progresse pas. Elle repart en boucle.

Dans cette boucle, le LLM reçoit une nouvelle tentative, éventuellement avec un contexte plus précis, un prompt corrigé ou un périmètre plus restreint. Cette boucle n’est pas un état d’échec. C’est un comportement intentionnel. C’est ce qui rend le système fiable plutôt que simplement optimiste.

Pour de nombreuses équipes, c’est aussi là que la gouvernance devient pratique plutôt qu’abstraite. Un transfert validé crée un endroit où consigner les décisions, examiner les échecs, définir des chemins d’escalade et maintenir l’intervention humaine lorsque le système ne peut pas satisfaire à ses propres exigences. Ces contrôles sont particulièrement importants dans les workflows où les erreurs affectent les clients, les registres financiers, les processus de conformité ou les systèmes internes de référence.

En pratique, cela change les priorités des équipes. La couche LLM doit être évaluée sur la qualité et la cohérence de ses sorties structurées, et non sur le caractère impressionnant de ses réponses. La couche d’exécution doit être évaluée sur sa fiabilité, et non sur sa flexibilité. La couche de validation entre les deux doit être considérée comme une composante de premier ordre de l’architecture, et non comme une réflexion après coup ajoutée une fois qu’un problème survient.

L’architecture elle-même est simple. Maintenir la frontière est le vrai travail.

Une prédiction modeste

Une grande partie de la conversation actuelle sur l’IA se concentre sur les modèles : quel modèle est le plus intelligent, le plus rapide ou le moins coûteux ; quel benchmark il a dépassé ; et de combien. Cette conversation pourrait ne pas rester utile très longtemps.

Les modèles deviennent des commodités plus rapidement que beaucoup ne l’avaient prévu. L’écart de capacités entre les principales options se réduit, les coûts de changement sont faibles, et le rythme d’amélioration signifie qu’un modèle choisi aujourd’hui peut être obsolète dans quelques mois. Arrimer un système opérationnel à un modèle spécifique commence déjà à ressembler à une erreur stratégique.

L’architecture autour du modèle n’est pas une commodité. Un système conçu autour d’une frontière nette entre raisonnement et exécution ne dépend pas du modèle qui s’y trouve. Lorsqu’une meilleure option devient disponible, le modèle peut être remplacé. Les workflows continuent de fonctionner, la logique de validation reste intacte et le système ne casse pas.

Cela fait de la portabilité un enjeu opérationnel, et pas seulement une préférence technique. Les équipes qui gardent séparés les prompts, les schémas, les règles de validation et la logique d’exécution sont mieux placées pour tester différents modèles sans reconcevoir l’ensemble du workflow autour de chacun d’eux.

Model Context Protocol et des standards similaires vont dans une direction utile. Ils fournissent aux LLM des interfaces standardisées pour se connecter à des systèmes externes, ce qui réduit considérablement les frictions d’intégration. Mais la connexion n’est pas la même chose que la conformité. Savoir comment atteindre un système et savoir comment produire une sortie que ce système acceptera sans se rompre sont deux problèmes distincts.

Les MCPs répondent au premier problème. La couche de validation, la conception de la frontière et la logique de boucle restent de la responsabilité des équipes qui construisent le système opérationnel. La plomberie s’améliore, mais ce qui y circule doit toujours être correct.

Les équipes qui avanceront le plus vite ne seront pas nécessairement celles qui auront choisi le meilleur modèle. Ce seront celles qui auront rendu le modèle remplaçable.