Qui configure l’orchestrateur ? Le vrai rôle de l’humain dans l’IA moderne

Introduction

Depuis quelques mois, une idée revient en boucle dans les discours sur l’IA : « elle est capable de tout faire toute seule ». Elle comprend le besoin, choisit les bons outils, appelle les bonnes APIs, prend des décisions pertinentes… presque comme un collaborateur autonome. Cette vision est séduisante. Elle est aussi profondément trompeuse.

Dans la réalité des projets — surtout internes aux entreprises, contraints par leurs données, leurs règles métiers et leurs exigences de sécurité — le LLM ne fait jamais tout seul. Il orchestre, mais il n’invente ni le cadre, ni les règles du jeu. Ce cadre est conçu, balisé et sécurisé par des humains : développeurs, architectes, data scientists, parfois même métiers.

Dans cet article, on va lever le voile sur un point clé souvent mal compris :
👉 qui configure réellement l’orchestrateur IA, et jusqu’où va son autonomie ?

Nous allons distinguer clairement :

• ce qui relève des responsabilités humaines,

• ce que le LLM fait réellement,

• et comment cette répartition évolue selon le niveau de maturité du projet.

Objectif : sortir du fantasme, pour entrer dans une compréhension opérationnelle et réaliste de l’IA moderne.

Dans l’article suivant, on se posera une question encore plus concrète : combien ça coûte… et qui travaille réellement sur ces projets ?

Le mythe : « L’IA sait tout faire seule »

Depuis l’explosion des LLMs dans le grand public, une croyance s’est installée presque naturellement : l’IA serait capable de comprendre un besoin, décider quoi faire et agir sans intervention humaine. On la décrit comme autonome, auto-apprenante, presque consciente de son environnement technique.

Cette perception est largement nourrie par les démonstrations spectaculaires : un prompt, et l’IA génère du code, appelle une API, analyse des données, produit un livrable cohérent. Vu de l’extérieur, tout semble fluide, instantané… et surtout sans configuration préalable apparente.

Le raccourci est alors rapide :

« Si elle sait écrire du code et discuter comme un humain, elle doit bien savoir se brancher toute seule sur nos systèmes. »

C’est ici que le mythe se construit.

En réalité, ce que l’on observe n’est pas une IA qui sait tout faire, mais une IA à qui l’on a déjà tout préparé :

• les outils qu’elle peut utiliser,

• les APIs qu’elle a le droit d’appeler,

• les règles qu’elle ne doit pas enfreindre,

• les scénarios qu’elle est autorisée à enchaîner.

Le LLM donne une illusion d’autonomie, car il raisonne, explique et décide dans un cadre invisible pour l’utilisateur. Mais sans ce cadre, il ne peut ni agir sur un système réel, ni garantir la moindre fiabilité. Croire que l’IA moderne s’auto-configure revient à confondre intelligence conversationnelle et responsabilité opérationnelle. Or, dans les projets sérieux, cette responsabilité reste — et restera longtemps — humaine.

Réalité : l’humain définit toujours le périmètre

Derrière chaque IA dite « autonome », il y a une réalité beaucoup plus terre-à-terre : quelqu’un a décidé ce qu’elle avait le droit de faire… et surtout de ne pas faire. Ce quelqu’un, ce sont des humains — développeurs, architectes, data scientists, experts sécurité, parfois même des métiers.

Dans un projet réel, le LLM n’évolue jamais dans un espace libre. Il est enfermé volontairement dans un périmètre fonctionnel, technique et organisationnel clairement défini. Ce périmètre répond à des contraintes très concrètes : sécurité des données, conformité réglementaire, fiabilité des résultats, responsabilité juridique.

Concrètement, l’humain décide :

• quels systèmes sont accessibles (et lesquels ne le seront jamais),

• quels types d’actions sont autorisés,

• dans quelles conditions une action peut être déclenchée,

• quand l’IA doit s’arrêter et demander une validation.

Le LLM, lui, n’a aucune conscience de ces enjeux. Il ne « comprend » ni les risques métiers, ni les contraintes légales, ni les impacts financiers. Il applique ce qu’on lui a donné, avec une remarquable capacité d’adaptation… mais sans libre arbitre.

C’est précisément cette définition du périmètre qui transforme une démonstration impressionnante en un système exploitable en entreprise.
Sans cadre clair, l’IA est au mieux inutile, au pire dangereuse. Avec un cadre bien conçu, elle devient un outil puissant, mais toujours sous contrôle.

Autrement dit : l’IA moderne ne commence pas par un prompt. Elle commence par une décision humaine de conception.

Ce que configure l’humain

Les Tools / Functions

La première brique — et sans doute la plus structurante — que l’humain configure dans un système d’IA moderne, ce sont les tools (ou functions).
Contrairement à une idée répandue, un LLM ne sait pas appeler n’importe quelle fonction par magie. Il ne peut utiliser que celles qui lui ont été explicitement déclarées.

Un tool est, en pratique, une capacité d’action mise à disposition du LLM :

• appeler une API interne,

• lancer un calcul,

• interroger une base de données,

• déclencher un workflow,

• produire un résultat structuré.

Ces tools sont définis par des humains, avec :

• un nom explicite,

• une description claire de leur rôle,

• un schéma d’entrée strict (types, champs obligatoires, formats),

• parfois des contraintes métier intégrées.

Le rôle du LLM n’est donc pas de créer des fonctions, mais de choisir intelligemment parmi celles qu’on lui propose. S’il n’existe pas de tool pour “créer un client”, “calculer un risque” ou “valider une commande”, le LLM ne pourra jamais le faire, même s’il “comprend” parfaitement la demande.

C’est ici que le travail du développeur et de l’architecte est central :
ils transforment des capacités techniques et métiers en interfaces exploitables par l’IA. Un bon design de tools facilite la décision du LLM ; un mauvais design la rend floue, fragile, voire erronée.

En résumé :

Les tools sont le vocabulaire d’action du LLM.
L’humain écrit le dictionnaire.
Le LLM ne fait que parler avec les mots qu’on lui a donnés.

Les Règles Métiers

Une fois les tools définis, il reste une question fondamentale : quand et comment faut-il les utiliser ? La réponse ne vient jamais du LLM lui-même, mais des règles métier définies par l’humain.

Les règles métier traduisent la réalité de l’entreprise : ses contraintes, ses priorités, ses exceptions, ses zones de risque. Ce sont elles qui déterminent ce qui est acceptable, autorisé, interdit ou conditionnel. Et contrairement à un humain, un LLM ne les devine pas.

Ces règles peuvent prendre plusieurs formes :

• conditions explicites (« si le client est inactif, interdire l’action »),

• seuils (montant maximum, score minimum, nombre de tentatives),

• enchaînements contrôlés (validation obligatoire avant exécution),

• cas particuliers que seule l’expérience métier permet d’anticiper.

Elles sont parfois codées directement dans les tools, parfois exprimées dans le prompt système, parfois implémentées dans une couche d’orchestration externe. Peu importe la forme : elles ne sont jamais émergentes. Elles sont conçues, écrites et maintenues par des humains.

Le LLM, lui, se contente de raisonner à l’intérieur de ces règles. Il peut proposer une action, expliquer une décision, reformuler une situation… mais il ne sait pas arbitrer seul entre ce qui est conforme ou non au métier si cette logique ne lui a pas été fournie.

C’est un point clé souvent sous-estimé :

plus un domaine est critique, réglementé ou complexe, plus la part de règles métier explicites augmente, et moins l’IA est “libre”.

L’intelligence du système ne vient donc pas seulement du modèle, mais de la qualité de formalisation du métier qui l’entoure.

APIs autorisées

Parmi les éléments les plus critiques configurés par l’humain figurent les APIs que le LLM est autorisé à appeler. Contrairement à une idée très répandue, un LLM n’a aucune capacité native à explorer un SI ou à “découvrir” des endpoints par lui-même.

Chaque API accessible à l’IA est :

• explicitement déclarée,

• documentée,

• encapsulée dans un tool ou un connecteur,

• protégée par des mécanismes d’authentification et de contrôle.

Autrement dit, l’IA ne voit qu’une façade volontairement réduite du système d’information. Elle n’a accès ni aux APIs techniques sensibles, ni aux fonctions internes critiques, ni aux zones grises que seuls les humains savent gérer.

Ce choix est loin d’être purement technique. Autoriser une API, c’est :

• exposer une capacité métier,

• accepter un niveau de risque,

• définir un périmètre de responsabilité.

C’est pourquoi les équipes sélectionnent soigneusement :

• quelles APIs sont exposées à l’orchestrateur,

• avec quels paramètres,

• dans quels scénarios,

• et sous quelles conditions de contrôle ou de validation.

Le LLM, de son côté, ne fait qu’utiliser ce catalogue autorisé.
S’il n’existe pas d’API pour une action donnée, il ne peut que l’expliquer, la simuler ou la refuser — jamais l’exécuter.

Cette restriction volontaire est un pilier de l’IA en entreprise :

l’intelligence est déléguée, l’accès reste maîtrisé.

Limites de sécurité

Les limites de sécurité sont le dernier rempart — et sans doute le plus décisif — entre une IA utile et une IA dangereuse.
Là encore, le LLM ne définit rien : il subit des garde-fous conçus et imposés par l’humain.

Ces limites existent à plusieurs niveaux :

• contrôle des données accessibles (périmètre, anonymisation, masquage),

• restrictions sur les actions possibles (lecture seule, écriture conditionnelle, interdiction de suppression),

• quotas et seuils (volumétrie, fréquence, coût),

• mécanismes de validation humaine (human-in-the-loop),

• journalisation et traçabilité des décisions.

Aucune de ces protections n’émerge spontanément du modèle. Un LLM peut respecter une règle de sécurité, mais il ne sait ni l’inventer, ni en mesurer les conséquences juridiques, financières ou réputationnelles. Dans un contexte d’entreprise, la sécurité ne se limite pas à “éviter les hallucinations”. Elle concerne :

• la conformité réglementaire (RGPD, normes internes),

• la séparation des rôles,

• la responsabilité en cas d’erreur,

• la capacité à auditer a posteriori ce que l’IA a fait… et pourquoi.

C’est pourquoi les architectures sérieuses multiplient les couches de protection en dehors du LLM : proxies, contrôleurs d’accès, moteurs de règles, validations explicites. Le modèle reste volontairement sous surveillance.

Cette réalité est souvent contre-intuitive pour le grand public, mais elle est essentielle :

plus une IA est puissante, plus les limites de sécurité doivent être strictes.

Et ces limites, contrairement au mythe, ne sont jamais décidées par l’IA elle-même.

Ce que fait le LLM

Décision dans un cadre

Une fois les tools définis et les règles métier posées, le LLM entre réellement en jeu. Son rôle n’est pas d’inventer le système, mais de prendre des décisions à l’intérieur d’un cadre strictement délimité. Concrètement, le LLM analyse une intention exprimée en langage naturel, la met en relation avec :

• les tools disponibles,

• les règles métier connues,

• le contexte de la conversation,

• l’historique des actions précédentes.

À partir de là, il choisit.

• Choisir d’appeler un tool plutôt qu’un autre.

• Choisir de demander une précision à l’utilisateur.

• Choisir de reformuler, de temporiser, ou de refuser une action.

Cette capacité de décision donne l’impression d’une grande autonomie, mais elle reste contextuelle et bornée. Le LLM n’explore pas librement un système d’information, il navigue dans un espace de possibilités conçu à l’avance.

On peut voir le LLM comme un excellent chef d’orchestre :

• il sait quand faire intervenir chaque instrument,

• il adapte le rythme à la situation,

• il maintient la cohérence de l’ensemble.

Mais il ne compose ni la partition, ni les règles musicales, ni la liste des instruments. S’il sort du cadre, c’est par erreur — jamais par intention. C’est précisément cette capacité à décider sans transgresser qui fait la valeur du LLM en entreprise : il réduit la complexité d’usage des systèmes, sans en prendre le contrôle.

Chaînage d’outils

L’une des forces majeures des LLMs modernes n’est pas l’exécution brute, mais leur capacité à enchaîner intelligemment des outils pour atteindre un objectif. C’est ce qu’on appelle le chaînage d’outils.

Face à une demande complexe, le LLM est capable de :

• décomposer le besoin en sous-étapes,

• identifier quel tool utiliser à chaque étape,

• exploiter le résultat d’un tool comme entrée du suivant,

• maintenir la cohérence globale du raisonnement.

Par exemple : comprendre une demande → récupérer des données → appliquer une règle → produire une synthèse → déclencher une action conditionnelle.

Ce qui est important ici, c’est que le LLM ne crée pas le workflow au sens classique. Il n’exécute pas un BPM figé. Il oriente dynamiquement l’enchaînement, en fonction du contexte et des réponses obtenues, tout en restant strictement limité aux tools autorisés.

Cette capacité donne une impression de raisonnement « stratégique ». En réalité, il s’agit d’une orchestration adaptative :

• les briques sont connues,

• les transitions sont évaluées,

• les impasses sont détectées,

• les incohérences peuvent être signalées.

Mais dès qu’un maillon manque, le LLM s’arrête.

• Pas de tool, pas d’action.

• Pas de règle claire, pas de décision fiable.

Le chaînage d’outils est donc l’endroit précis où la complémentarité humain / IA devient visible :

• l’humain conçoit les briques,

• le LLM choisit l’ordre et le moment,

• le système reste contrôlable et explicable.

C’est cette mécanique qui transforme un simple chatbot en orchestrateur opérationnel, sans jamais lui donner les clés du système.

Gestion des conversations

Au-delà des décisions et du chaînage d’outils, le LLM joue un rôle clé souvent sous-estimé : la gestion de la conversation. C’est là que sa valeur devient immédiatement perceptible pour les utilisateurs.

Le LLM est capable de :

• maintenir le contexte sur plusieurs échanges,

• interpréter des demandes incomplètes ou ambiguës,

• reformuler pour validation,

• adapter son discours au niveau de l’interlocuteur,

• expliquer ses choix ou ses limites.

Cette gestion conversationnelle permet de transformer des systèmes complexes en interfaces naturelles. Là où, auparavant, l’utilisateur devait connaître les écrans, les champs, les règles et les parcours, il peut désormais dialoguer de manière fluide, progressive et tolérante à l’imprécision.

Mais là encore, il faut être clair : le LLM ne “comprend” pas le métier comme un humain. Il gère un état conversationnel, pas une intention stratégique globale. Il conserve ce qu’on lui donne comme contexte, il n’en crée pas de nouveau de manière fiable.

C’est précisément pour cela que la conversation devient un outil de sécurisation :

• le LLM peut poser des questions avant d’agir,

• demander des confirmations explicites,

• signaler une incohérence ou un manque d’information,

• refuser poliment une action hors périmètre.

En entreprise, cette capacité est déterminante : elle permet de ralentir intelligemment l’exécution quand le risque augmente, sans casser l’expérience utilisateur.

En résumé :

le LLM est moins un exécutant qu’un médiateur conversationnel entre l’humain et le système.

Et cette médiation, bien configurée, est souvent ce qui fait toute la différence entre un gadget et un outil réellement adopté.

Niveaux de maturité de l’orchestration IA

Tous les systèmes d’IA orchestrée ne se valent pas. Selon la maturité technique et organisationnelle de l’entreprise, la relation entre l’humain, le LLM et les outils évolue fortement. On peut distinguer trois niveaux de maturité courants.

Niveau 1 — Tools figés

C’est le niveau le plus simple… et le plus répandu aujourd’hui.

Le LLM dispose d’un ensemble restreint de tools, définis à l’avance et rarement modifiés. Chaque tool correspond à une action précise, souvent directement liée à un cas d’usage unique.

Caractéristiques :

• tools codés en dur,

• périmètre fonctionnel très clair,

• peu ou pas d’adaptation dynamique,

• sécurité maximale, mais flexibilité limitée.

Ce niveau est idéal pour :

• des assistants spécialisés,

• des POCs encadrés,

• des usages critiques où le risque doit être minimal.

Le LLM orchestre, mais dans un couloir très étroit.

Niveau 2 — Bibliothèque de tools

Ici, on passe à une logique plus industrielle.

Le LLM a accès à une bibliothèque de tools plus large, structurée et maintenable. Les tools sont conçus pour être réutilisables et combinables entre plusieurs cas d’usage.

Caractéristiques :

• catalogue de tools versionné,

• descriptions riches et standardisées,

• capacité de chaînage plus complexe,

• évolution continue sans refonte globale.

Ce niveau permet :

• une meilleure couverture fonctionnelle,

• une montée en puissance progressive,

• une séparation claire entre conception des tools et orchestration.

Le LLM commence à choisir intelligemment parmi plusieurs options, sans jamais sortir du périmètre autorisé.

Niveau 3 — Découverte d’APIs via catalogue

C’est le niveau le plus avancé — et le plus exigeant.

Le LLM n’a plus une liste statique de tools, mais un catalogue d’APIs décrites et gouvernées, qu’il peut explorer pour identifier celles qui répondent le mieux à une intention donnée.

Attention : il ne s’agit pas d’un accès libre. Le catalogue est :

• validé,

• documenté,

• sécurisé,

• filtré par rôle et contexte.

Caractéristiques :

• métadonnées riches (fonction, risques, coûts),

• règles d’éligibilité dynamiques,

• supervision renforcée,

• forte exigence d’architecture et de gouvernance.

À ce niveau, le LLM ne devient pas autonome : il devient plus adaptable, tout en restant strictement contrôlé.

Conclusion

À la fin de cet article, une chose devrait être claire : l’orchestrateur IA n’est pas autonome, il est encadré.

Le LLM n’est ni un développeur fantôme, ni un architecte invisible, ni un décideur métier. C’est un moteur de raisonnement et d’orchestration, extrêmement performant, mais fondamentalement dépendant du cadre que les humains ont conçu pour lui.

Ce cadre — tools, règles métier, APIs autorisées, limites de sécurité — représente l’essentiel de la valeur réelle d’un projet d’IA en entreprise. Le modèle, aussi impressionnant soit-il, n’est qu’un amplificateur de cette conception. Plus le système paraît “intelligent” et fluide à l’usage, plus il est probable que :

• le travail humain en amont a été important,

• l’architecture a été pensée avec soin,

• les responsabilités ont été clairement réparties.

C’est là que beaucoup de discours sur l’IA se trompent : ils surestiment l’autonomie du modèle et sous-estiment massivement le travail d’ingénierie, de gouvernance et de design qui le rend exploitable. Comprendre cette réalité, c’est sortir du fantasme… et entrer dans une vision professionnelle, durable et maîtrisée de l’IA moderne.

Maintenant que les rôles sont clairs, une question devient inévitable : qui fait quoi, concrètement, dans un projet d’IA orchestrée… et à quel coût ?

Dans le prochain article, on quittera le terrain conceptuel pour entrer dans le très concret :

• quels profils interviennent réellement (dev, architecte, data, métier),

• comment se répartit l’effort entre humain et IA,

• où se situe le vrai coût d’un projet,

• et pourquoi un POC “simple” peut vite devenir complexe.

Spoiler : le coût n’est pas là où beaucoup l’imaginent… et ce n’est pas le LLM qui fait le plus gros du travail.