Concevoir l’environnement d’exécution d’un agent : choisir le bon modèle

Le routage des modèles est une question de contrôle opérationnel, pas un concours de classement. Les exigences de confidentialité et de résidence des données définissent d’abord l’ensemble des modèles admissibles. La réussite des tâches et la qualité des résultats déterminent ensuite les solutions adaptées au sein de cet ensemble. Ce n’est qu’après que l’on optimise le nombre de tokens, la latence et le coût. Les modèles locaux peuvent être efficaces, mais nécessitent généralement une décomposition plus poussée, une meilleure recherche d’informations et des vérifications déterministes.

L’environnement d’exécution est l’unité productive

Un agent d’entreprise ne se résume pas à un modèle assorti d’un long prompt système. Il repose sur un environnement d’exécution : réception des demandes, assemblage du contexte, contrôles de conformité, exécution du modèle, accès aux outils, état, vérification, logique de nouvelle tentative, observabilité et remontée des exceptions. Le modèle n’est qu’un composant remplaçable de cet ensemble.

Les comparaisons effectuées hors de cet environnement prédisent souvent mal les résultats en production. Un modèle performant sur un benchmark peut peiner avec les formats, droits d’accès, vocabulaire ou flux de travail de l’entreprise. Un autre, moins convaincant en conversation ouverte, peut se montrer fiable quand la tâche est décomposée, les preuves récupérées et les résultats vérifiés selon des contraintes déterministes.

Choisir « le meilleur modèle » est donc une abstraction inadaptée. Nous choisissons un chemin d’exécution admissible pour une tâche définie. Il peut mobiliser un modèle, plusieurs appels spécialisés, un modèle local ou hébergé, voire aucun modèle. Il ne réussit que si la tâche atteint un état métier vérifié.

L’architecture doit rendre ce caractère remplaçable explicite. Une couche d’opérations IA organisée par threads sépare le contexte utilisateur de l’exécuteur, afin que le routage, l’état, les autorisations et les vérifications restent stables lorsque le modèle change.

Premier contrôle : confidentialité, résidence des données et admissibilité contractuelle

Le routage commence avant les tests de qualité. La première question est de savoir si le point de terminaison du modèle est autorisé à recevoir les données et à effectuer l’action.

Nous établissons un profil d’admissibilité pour chaque classe de tâches. Il couvre :

la classification des données et la présence d’informations personnelles, confidentielles, réglementées ou soumises au contrôle des exportations ;
les régions requises pour le traitement et le stockage ;
les conditions de conservation, de journalisation, d’utilisation pour l’entraînement et de suppression ;
les sous-traitants ultérieurs et les contraintes de transfert transfrontalier ;
les exigences de chiffrement, d’identité et de contrôle d’accès ;
les obligations de journalisation d’audit et de notification des incidents ;
la possibilité pour les outils de lire ou de modifier les systèmes en production ;
la possibilité de sortir les documents récupérés d’un environnement contrôlé.

Ce sont des contraintes de routage, pas un paragraphe de politique ajouté après le lancement. Le routeur doit exclure les points de terminaison qui ne satisfont pas le profil lorsque la tâche contient des données soumises à restriction. La suppression des informations sensibles peut parfois créer une tâche dérivée moins restreinte, mais elle doit être fiable, journalisée et testée pour les formats concernés. Remplacer un nom tout en conservant un numéro de compte unique ou une combinaison de faits commercialement sensibles n’est pas une anonymisation effective.

La résidence des données concerne aussi l’environnement d’exécution : envoyer les prompts vers un point de terminaison régional approuvé ne suffit pas si les traces, index vectoriels, journaux d’erreur ou files de contrôle humain sont stockés ailleurs. Nous examinons tout le parcours des données : réception, fichiers temporaires, recherche, inférence, résultats des outils, observabilité, sauvegardes et accès de l’assistance.

Ce contrôle détermine les chemins permis, sans désigner de gagnant. Un modèle local peut être obligatoire pour une tâche, facultatif pour une autre et inadapté pour une troisième. La politique réduit le choix ; les preuves le complètent.

Deuxième contrôle : réussite de la tâche, puis qualité

Dans l’ensemble admissible, la première question est la réussite de la tâche : le flux de travail a-t-il atteint l’état prévu ? En recherche, il peut s’agir d’une réponse étayée avec des citations dont les sources sont accessibles. En extraction, d’un enregistrement conforme au schéma et relié aux passages sources. Pour une action opérationnelle, d’un plan valide d’exécution à blanc, d’une modification approuvée et d’une vérification après action réussie.

La réussite dépasse la qualité de la réponse : un texte éloquent mais impossible à analyser, citant des preuves indisponibles ou appelant un outil interdit constitue un échec. À l’inverse, un résultat succinct peut réussir s’il termine le processus de façon fiable.

Nous construisons un jeu d’évaluation à partir de tâches représentatives. Chaque cas contient l’entrée, les preuves autorisées, la transition d’état attendue, les conditions d’échec rédhibitoires et la grille d’évaluation. Il doit couvrir :

les cas courants qui dominent le volume ;
les cas proches d’un seuil de politique ou de qualité ;
les entrées manquantes, obsolètes, dupliquées ou contradictoires ;
les pannes d’outils et de dépendances ;
les tentatives d’injection de prompt ou d’exploitation de contenus non fiables ;
les cas où il faut s’abstenir ou solliciter une intervention ;
les variations de langue ou de format, si elles sont pertinentes.

Nous évaluons les contraintes impératives avant les préférences subjectives. Validité du schéma, sélection correcte de l’outil, respect des autorisations, citations étayées et abstention requise sont des critères de réussite ou d’échec. L’exhaustivité sémantique, la clarté et l’utilité peuvent être notées selon une grille. Une prose plus soignée ne compense pas un taux inférieur de tâches terminées et vérifiées.

Les skills d’agents spécialisés par domaine stabilisent l’évaluation en consignant les procédures et contrôles dans des ressources explicites plutôt que de les redécouvrir à chaque conversation.

Troisième contrôle : tokens, latence et coût

Nous n’optimisons l’efficacité qu’après satisfaction des critères de réussite et de qualité. L’unité pertinente est le coût par tâche vérifiée, pas le prix par token d’entrée.

Un modèle moins cher peut coûter plus s’il exige de nouvelles tentatives, des contrôles humains ou des corrections en aval. Une première réponse rapide peut masquer une mauvaise latence de bout en bout si l’environnement répare constamment les résultats invalides. Une fenêtre de contexte plus grande peut encourager le chargement indiscriminé, accroître le coût et multiplier les possibilités d’erreur.

Nous mesurons les dimensions suivantes :

Dimension	Mesure au niveau de l’environnement d’exécution
Réussite	tâches terminées et vérifiées par tentative admissible
Qualité	acceptation au premier passage, gravité des défauts et taux de défauts non détectés
Tokens	tokens d’entrée, d’entrée en cache, de sortie et de nouvelle tentative par tâche terminée et vérifiée
Latence	durée médiane et durée des cas les plus longs, du déclenchement à l’état vérifié
Coût	inférence, recherche d’informations, outils, contrôle et reprise du travail par tâche terminée et vérifiée
Stabilité	variation des performances dans le temps, selon les formats et les classes de demandes

Les indices normalisés rendent les comparaisons internes lisibles sans suggérer une fausse précision. La route approuvée actuelle reçoit une référence = 100 pour le coût ajusté à la qualité et la latence de bout en bout. Un candidat n’est utile que si son indice de coût inférieur ne masque pas une baisse de réussite, une hausse des exceptions ou du temps de contrôle humain. Nous conservons les décomptes et définitions sous-jacents pour l’audit, même lorsque les rapports externes utilisent des indices normalisés.

L’optimisation devient alors ciblée. La mise en cache des prompts peut réduire le contexte de politique répété. Des passages sources plus courts peuvent limiter les distractions. La lecture en parallèle via les outils peut réduire la latence. Un modèle plus petit peut prendre en charge la classification, tandis qu’un chemin plus puissant traite les synthèses ambiguës. Du code déterministe peut supprimer entièrement un appel d’inférence.

Router les tâches, pas les utilisateurs

Le routage statique par service gaspille des capacités et de l’argent. Une même personne peut demander un résumé public, une comparaison confidentielle, un rapprochement et une écriture en production : ces classes de tâches ont des exigences différentes d’admissibilité, de qualité et de périmètre d’action autorisé.

Nous routons les tâches à partir d’une enveloppe explicite :

task_type: extract | classify | synthesize | plan | act | verify
data_class: public | internal | confidential | restricted
residency: approved_regions
authority: read | recommend | dry_run | approved_write
evidence: source_ids and freshness requirements
output_contract: schema or rubric version
risk: consequence and reversibility
latency_budget: interactive | asynchronous | batch

Le routeur doit être aussi déterministe que possible. La classification des données, leur résidence et le périmètre d’action autorisé sont des décisions de politique ; ils ne doivent pas dépendre d’un modèle qui devine si une demande « paraît sensible ». Un classificateur peut aider à traiter la demande initiale, mais l’incertitude doit conduire vers le chemin plus sûr ou vers une clarification précise.

Le choix du modèle intervient ensuite dans la branche autorisée. Le chemin est enregistré avec les versions de la politique, du modèle, du prompt ou du skill, les identifiants des preuves récupérées, les appels d’outils, les résultats des vérificateurs et l’état final. Cette trace permet de diagnostiquer les échecs et de reproduire les comparaisons.

Pourquoi les modèles locaux nécessitent un autre environnement d’exécution

L’inférence locale est souvent présentée comme un simple déplacement du même prompt d’un service hébergé vers son propre matériel. Cela suffit rarement. Les modèles locaux peuvent offrir un contrôle élevé de la confidentialité, un coût marginal prévisible, un fonctionnement hors ligne et une faible latence pour les tâches délimitées. Leur respect des instructions, leur sélection des outils, leur fiabilité sur de longs contextes ou leur cohérence multilingue peuvent être inférieurs à ceux des meilleures solutions hébergées du moment.

La bonne réponse n’est pas de masquer ces différences, mais d’adapter l’environnement d’exécution.

Décomposer davantage

Confiez au modèle une seule transformation délimitée à la fois. Séparez sélection des documents, extraction, classification, rédaction et vérification. Chaque étape doit avoir un contrat d’entrée et de sortie restreint. La décomposition réduit les instructions simultanées et crée des points de contrôle où des mécanismes déterministes peuvent arrêter la propagation des erreurs.

Un chemin local peut d’abord identifier les sections pertinentes, extraire les affirmations dans un schéma, relier chacune à un passage source, puis rédiger uniquement à partir des affirmations acceptées. Cela demande davantage d’orchestration qu’un grand prompt unique, mais facilite l’évaluation et la correction.

Récupérer moins, mais mieux

Charger un dépôt entier ou une collection de documents dans le contexte n’est pas de la recherche d’informations : cela transfère au modèle le problème de sélection. Les chemins locaux bénéficient d’index structurés, de filtres de métadonnées, de critères de fraîcheur et de courts ensembles de preuves. La recherche doit fournir les identifiants et les passages sources afin que les contrôles en aval puissent confirmer l’appui documentaire de la réponse.

Les pratiques de construction d’un assistant IA local avec recherche documentaire et recherche web montrent pourquoi l’inférence locale dépend d’une couche d’outils et de preuves plutôt que de la seule mémoire du modèle.

Vérifier de façon déterministe

Utilisez autant que possible des schémas, analyseurs syntaxiques, listes d’autorisation, contraintes de base de données, calculs, moteurs de règles et vérifications après action. Un modèle peut proposer un changement ; le code doit confirmer la présence des champs requis, la validité des identifiants, la concordance des totaux, les droits nécessaires et la correspondance entre l’état final et le plan approuvé.

Pour les contrôles sémantiques non déterministes, utilisez une grille et un chemin de contrôle indépendant. Ne demandez pas au même appel de générer, noter et approuver son résultat. Si un modèle sert d’évaluateur, calibrez-le sur des jugements humains et excluez-le du périmètre d’autorisation final.

Cascades, solutions de repli et abstention

Un routeur utile n’envoie pas toutes les tâches admissibles au modèle le plus puissant. Il peut utiliser une cascade : commencer par le chemin le moins coûteux ayant déjà satisfait aux critères d’acceptation de la classe de tâches, puis solliciter un niveau supérieur sur échec observable.

Les signaux d’escalade doivent être concrets : schéma encore invalide après correction, preuves manquantes, sources contradictoires, faible confiance calibrée, outil indisponible, limite de politique ou échec de vérification. Le nombre de tokens n’est pas un indicateur de qualité. L’incertitude déclarée par le modèle ne l’est pas non plus sans calibration pour la tâche.

Les solutions de repli doivent rester cohérentes sur le plan sémantique. Si le chemin principal échoue parce qu’il ne peut pas satisfaire aux exigences de résidence des données, la solution de repli ne peut pas les ignorer. Si un appel d’outil est indisponible, un chemin limité au chat ne doit pas prétendre que l’action a eu lieu. Si les preuves sont obsolètes, un modèle plus puissant ne peut pas les rendre actuelles.

L’abstention est une réussite lorsque le contrat exige une remontée des exceptions. Nous comptons les refus ou remontées corrects parmi les réussites ; sinon, la pression du routage récompense les actions dépassant les preuves ou les droits disponibles.

État, versions et reproductibilité

Les modèles et points de terminaison évoluent. Même sous un nom inchangé, le comportement peut varier avec la version, la configuration de service, le prompt système, l’index de recherche, la définition des outils ou la politique. Il faut versionner tout le contrat d’exécution.

Nous conservons au minimum :

les versions de la tâche et de la politique ;
le fournisseur, la région du point de terminaison et la version du modèle ;
les versions du prompt, du skill et des schémas d’outils ;
la requête de recherche, les identifiants sources et les horodatages de fraîcheur ;
les paramètres d’échantillonnage et les délais d’expiration ;
les versions et les résultats des vérificateurs ;
les événements de nouvelle tentative, de recours à une solution de repli et de contrôle humain ;
l’action finale et les preuves de vérification après action.

La reproductibilité opérationnelle repose sur les entrées, configurations, actions externes et preuves de vérification, pas sur une chaîne de pensée sans restriction. Les traces sensibles suivent les règles de minimisation et de conservation de l’entreprise.

La discipline décrite dans le réglage d’un agent propre à un projet est pertinente : espaces de travail persistants et procédures réutilisables ne sont utiles que si changements, concurrence et modes de défaillance sont observables.

Un processus de sélection pratique

Nous utilisons un processus de sélection par étapes :

Définir les classes de tâches. Séparez extraction, synthèse, planification, action et vérification ; ne les réduisez pas à une note moyenne.
Appliquer les contrôles d’admissibilité. Éliminez les chemins qui ne satisfont pas aux exigences de confidentialité, de résidence, de contrat ou d’autorisation.
Construire le jeu d’évaluation. Incluez des cas représentatifs, des cas limites, des cas adversariaux et des cas exigeant une escalade, avec des preuves figées.
Exécuter les chemins dans l’environnement réel. Incluez recherche d’informations, outils, délais d’expiration, nouvelles tentatives et vérificateurs.
Contrôler les échecs rédhibitoires. Rejetez les chemins qui enfreignent les exigences de schéma, de preuves, d’autorisation ou d’abstention.
Évaluer réussite et qualité. Examinez les performances moyennes ainsi que les défauts les plus graves.
Mesurer l’efficacité totale. Comparez tokens, latence, coût d’inférence, temps de contrôle, nouvelles tentatives et reprises du travail par tâche terminée et vérifiée.
Tester en mode d’observation ou d’exécution à blanc. Observez les variations de la demande réelle sans autoriser d’écritures non vérifiées.
Approuver par classe de tâches. Consignez le chemin, ses limites, sa solution de repli et la date d’expiration de la décision.
Réévaluer en continu. Déclenchez un examen lors de changements de modèle, de dérives, de nouvelles classes de données, d’exceptions répétées ou de variations de prix importantes.

Le résultat est une politique de routage versionnée, pas un classement permanent.

La règle de décision

L’ordre des décisions fonde un routage responsable. Confidentialité, résidence des données et exigences contractuelles déterminent ce qui est permis. Réussite vérifiée et qualité déterminent ce qui est capable. Tokens, latence et coût total déterminent ce qui est efficace parmi les chemins restants.

Inverser cet ordre crée des échecs prévisibles : donner priorité au coût peut envoyer des données sensibles vers des points de terminaison inadmissibles ou multiplier les contrôles coûteux sur des résultats médiocres. Donner priorité au modèle adapte les processus à un fournisseur préféré ; donner priorité aux benchmarks optimise des tâches que l’entreprise n’effectue peut-être pas.

Nous concevons l’environnement pour que les modèles puissent changer sans perdre politique, état ou preuves. Modèles hébergés, modèles locaux et services déterministes ont chacun un rôle. Le bon choix est le plus petit système admissible qui termine la tâche définie, satisfait aux critères de qualité et prouve le résultat.

Analyses connexes

Architecture de référence pour une couche d’opérations IA par threads — routage, état typé, autorisation, exécution et vérification
Créer des skills d’agents IA pour des flux de travail métier spécialisés — procédures et contrôles spécialisés consignés dans des ressources externes
Construire un assistant IA local avec recherche web : configuration MCP + Ollama — un modèle pratique d’inférence locale, de recherche d’informations et d’outils