Le contexte compte plus que la taille du modèle
Le plus grand modèle d’IA est rarement la meilleure réponse à chaque problème d’entreprise. La véritable contrainte, c’est le contexte. Un système d’IA doit comprendre le client, le processus, les actions passées, les règles métier et la décision qu’on lui demande de prendre. Sans ces informations, même un modèle puissant doit déduire ce qui manque.
Ricky Thakrar, Head of Sales and Account Management chez Zoho, a décrit l’approche de l’entreprise comme étant « plus petite, plus intelligente, plus sûre » lors de l’événement CIO 100 Leadership Live New York. Le principe est simple. Utiliser des modèles plus petits lorsque la tâche le permet. Mettre davantage d’intelligence dans l’architecture autour du modèle. Vérifier les décisions importantes avant qu’une erreur ne s’intègre à un workflow.
Cela change la manière dont les dirigeants devraient envisager l’investissement dans l’IA. Une plus grande capacité de modèle ne produit pas automatiquement de meilleurs résultats business. Les modèles de pointe tels que la série GPT d’OpenAI, Claude d’Anthropic et Gemini de Google disposent de larges capacités de raisonnement. Selon Thakrar, une partie de cette capacité compense l’absence de contexte. Lorsqu’un système ne connaît pas l’historique des comptes d’une entreprise ni ses processus internes, le modèle doit faire davantage d’inférences.
Une couche de contexte solide réduit cette charge. Elle fournit au modèle des données d’entreprise pertinentes avant de lui demander de raisonner. Un modèle plus petit peut alors exécuter une tâche ciblée, car le système lui a déjà fourni une grande partie de ce qu’il doit savoir. Comme l’a formulé Thakrar, « l’intelligence se déplace du modèle vers l’architecture qui l’entoure ».
Cela a des implications qui vont au-delà du coût. L’architecture qui entoure le modèle peut contenir des connaissances propres à l’entreprise : règles métier, historique client, autorisations, états du workflow, étapes de validation et retours des employés. Cette couche peut devenir une capacité propriétaire. Le modèle sous-jacent, en revanche, peut être accessible à tous les concurrents utilisant le même fournisseur d’IA.
La priorité des dirigeants devrait donc être le contexte avant l’échelle du modèle. Commencez par définir quelles informations une tâche exige, où elles se trouvent et avec quelle fiabilité elles peuvent être récupérées. Sélectionnez ensuite une capacité de modèle suffisante pour accomplir la tâche. Acheter davantage d’intelligence avant de résoudre le problème du contexte peut augmenter les dépenses sans corriger la faiblesse sous-jacente.
Le même principe s’applique à la sécurité. La validation est plus utile lorsqu’elle intervient avant qu’une décision générée par l’IA ne devienne une action irréversible. Les systèmes agentiques peuvent faire plus que produire du texte. Ils peuvent mettre à jour des enregistrements, déclencher des workflows, contacter des clients ou interagir avec d’autres logiciels. L’architecture doit donc contrôler ce que l’agent peut faire, quelles informations il peut utiliser et à quel moment un contrôle humain ou déterministe est requis.
C’est pourquoi Thakrar affirme que le modèle est la partie la plus simple de l’IA d’entreprise. La tâche la plus difficile consiste à construire un système dans lequel les modèles, le contexte d’entreprise, les processus métier et le jugement humain fonctionnent ensemble. Ce système peut s’améliorer à mesure que les employés ajoutent des connaissances et corrigent les erreurs. Pour les entreprises, ce contexte accumulé comptera probablement davantage que le fait de passer sans cesse au modèle le plus récent.
L’agent de churn de Zoho montre le coût d’un contexte métier manquant
Une seule règle métier manquante a suffi à entamer la confiance dans l’un des premiers agents d’IA de Zoho en l’espace d’une semaine. Le problème était que l’agent disposait de données, mais ne comprenait pas ce que ces données signifiaient dans les processus métier de Zoho.
Zoho a développé un agent de gestion du churn pour son équipe de gestion de comptes. Lorsqu’un abonnement client devenait inactif, le système rassemblait des informations issues des notes de compte, des enregistrements de réunions et des outils d’enrichissement de données de Zoho. Il résumait ensuite les raisons possibles de ce churn apparent et planifiait un appel.
Le workflow semblait utile. L’interprétation sous-jacente était erronée dans des cas importants.
Le CRM de Zoho enregistre un bundle de produits comme une seule ligne. Lorsqu’un client existant transfère des produits achetés individuellement dans ce bundle, les anciens abonnements individuels passent à l’état inactif. La première version de l’agent traitait ces enregistrements inactifs comme une preuve de churn client. En réalité, le client avait regroupé ses produits au lieu de partir.
L’erreur a eu un effet organisationnel immédiat. « En une semaine, mon équipe ne faisait déjà plus confiance à cet agent », a déclaré Thakrar. Zoho a corrigé le problème du bundle dans la deuxième version, mais un autre élément de contexte manquant est vite apparu.
Certains clients achètent d’abord des produits Zoho pour des projets pilotes ou des environnements sandbox. Lorsqu’ils passent ensuite à un déploiement en production, ils arrêtent les versions pilotes. Le CRM enregistre à nouveau des abonnements devenant inactifs. L’événement sous-jacent peut indiquer une progression du client, mais un agent focalisé sur le statut de l’abonnement peut l’interpréter comme du churn.
Un troisième cas a rendu le problème encore plus clair. Les account managers déterminent parfois qu’un produit Zoho n’est pas le bon choix pour un client et recommandent un autre produit. Le churn qui en résulte est délibéré. Ce n’est pas la preuve que le compte est soudainement à risque. Une classification correcte exige donc de connaître l’intention de l’account manager.
Ces échecs mettent en évidence le problème central de l’IA d’entreprise : l’accès aux données n’est pas la même chose que la compréhension métier. Une base de données peut montrer qu’un abonnement est devenu inactif. Déterminer pourquoi il est devenu inactif peut exiger des connaissances réparties entre les enregistrements CRM, les conversations, les configurations produit, les processus commerciaux et les décisions des employés.
La confiance a aussi une valeur économique. Presque un an après le lancement de l’initiative autour de l’agent de churn, Thakrar a indiqué que son équipe vérifiait encore le travail de l’agent de manière indépendante. Le système avait rendu les employés plus attentifs au churn potentiel, mais le gain de productivité attendu n’était pas encore au rendez-vous. Si un employé doit refaire la recherche pour confirmer un résultat de l’IA, l’automatisation n’a pas supprimé beaucoup de travail.
Cette leçon devrait influencer la manière dont les dirigeants mesurent les déploiements d’agents. La précision initiale n’est qu’un indicateur parmi d’autres. Les équipes devraient aussi mesurer les taux de faux positifs, la part des résultats que les employés vérifient manuellement, le temps consacré à la vérification et l’évolution de la confiance après les corrections. Un agent qui accomplit techniquement une tâche mais déclenche un second processus manuel peut simplement déplacer le travail au lieu de l’éliminer.
Les exemples de Zoho étaient des échecs dus à un contexte et à des règles métier manquants. Un modèle plus performant ne peut pas déduire de manière fiable une convention CRM interne qu’on ne lui a jamais fournie. La réponse pratique consiste à capturer ces conventions, à les intégrer au workflow et à utiliser les corrections des employés pour améliorer le contexte disponible pour les décisions futures.
L’objectif actuel de Thakrar est plus large : créer un parcours client assisté par l’IA, de la vente à la gestion de compte, dans lequel le contexte client survit au transfert. Les informations recueillies pendant le processus commercial devraient rester disponibles et utiles une fois que le client devient un compte.
Pour les dirigeants, c’est l’investissement dans l’IA le plus important. Avant d’automatiser une décision métier, cartographiez les informations que les humains utilisent réellement pour la prendre. Incluez les exceptions, les transitions de processus, les décisions historiques et l’intention. Les agents d’entreprise deviennent précieux lorsqu’ils comprennent la signification opérationnelle des données qu’ils traitent.
Un projet en tête ?
Planifiez un appel de 30 minutes avec nous.
Des experts senior pour vous aider à avancer plus vite : produit, tech, cloud & IA.
Un routage intelligent peut réduire les coûts de l’IA en adaptant le modèle à la tâche
Un modèle de 3 milliards de paramètres peut réduire les coûts jusqu’à 95 % pour certaines charges de travail, selon Ricky Thakrar, Head of Sales and Account Management chez Zoho. Son propos n’est pas de dire que les modèles plus petits sont universellement meilleurs. Il est que la plupart des tâches d’entreprise n’ont pas besoin d’une puissance de calcul de niveau frontier.
Le problème de coût commence lorsque les entreprises envoient chaque requête à leur modèle le plus performant. Les modèles de pointe offrent une large capacité de raisonnement, mais cette capacité a un prix plus élevé. Thakrar a averti que les entreprises peuvent consommer en quelques mois un budget annuel de tokens prévu sur douze mois lorsqu’elles utilisent ces modèles sans discernement.
Le routage répond à ce problème. C’est le processus qui consiste à sélectionner le bon modèle pour chaque charge de travail. Une tâche simple de classification ou de validation peut être confiée à un petit modèle. Une tâche difficile qui exige un raisonnement important peut être confiée à un modèle de pointe. La capacité du modèle devient une ressource attribuée selon le besoin plutôt qu’un paramètre par défaut.
Le contexte rend cette approche praticable. Un modèle a souvent besoin d’une puissance de raisonnement supplémentaire parce que des informations clés manquent ou sont mal structurées. Si le système fournit d’abord l’historique client pertinent, l’état du processus, les règles métier et des instructions spécifiques à la tâche, un modèle plus petit peut être capable de produire le résultat requis de manière fiable.
Thakrar a indiqué que Zoho a observé chez certains clients des cas où l’utilisation d’un modèle de 3 milliards de paramètres pouvait permettre d’économiser 95 %. « Vous n’avez pas toujours à payer les acteurs de la frontier pour chaque tâche », a-t-il déclaré. Le chiffre de 95 % est une observation issue du travail de Zoho chez ses clients, et non un benchmark général pour toutes les charges de travail d’entreprise. Les économies réelles dépendront de la tarification des modèles, du volume des tâches, de la taille du contexte, des exigences de latence et de la fréquence à laquelle les requêtes doivent être escaladées vers un modèle plus grand.
Pour les dirigeants, le routage devrait donc être considéré à la fois comme un contrôle d’ingénierie et un contrôle financier. L’objectif n’est pas de maximiser le pourcentage de requêtes traitées par de petits modèles. Il est d’utiliser le modèle le moins coûteux capable d’atteindre de manière constante le niveau requis de précision, de vitesse et de maîtrise du risque.
Cela exige des mesures. Les entreprises doivent comparer les performances des modèles par tâche, surveiller les taux d’échec et définir à quel moment une requête doit être transférée vers un modèle plus performant. Les décisions à haut risque peuvent justifier des coûts de modèle plus élevés, même lorsqu’un modèle plus petit offre des performances correctes en moyenne. Les tâches répétitives à faible risque offrent un meilleur cas d’usage pour une optimisation agressive des coûts.
Cette approche réduit aussi la dépendance à un fournisseur d’IA unique. Une couche de routage efficace peut orienter les charges de travail entre différents modèles selon leurs capacités, leur coût, leur disponibilité ou les exigences de l’entreprise. Cela donne aux entreprises davantage de contrôle à mesure que les performances et les prix des modèles évoluent.
Le business case est clair. L’échelle du modèle doit suivre la complexité de la charge de travail. Les entreprises qui instaurent cette discipline peuvent réserver la capacité de raisonnement coûteuse aux tâches qui en ont besoin et réduire le coût des opérations d’IA de routine.
Le harness de l’agent peut compter davantage que le modèle sous-jacent
Un modèle de langage peut générer une réponse. Un agent d’entreprise doit faire davantage. Il peut avoir besoin de récupérer des enregistrements, d’utiliser des outils logiciels, de se souvenir d’une activité antérieure, de respecter des autorisations, de valider des résultats et d’exécuter une action. L’infrastructure qui coordonne ces fonctions est souvent appelée agent harness ou couche d’orchestration.
Thakrar soutient que cette couche a une importance pratique plus grande que la capacité brute du modèle. « C’est le processus autour du modèle qui compte bien plus que le modèle lui-même », a-t-il déclaré.
Le harness détermine quelles informations parviennent au modèle et ce qui se passe après que le modèle a produit un résultat. Il peut connecter un agent à des systèmes CRM, des bases de données, des applications internes, de la mémoire, des outils, des environnements d’exécution et des contrôles de sécurité. Il peut aussi restreindre les actions qu’un agent est autorisé à effectuer et exiger une vérification avant que des actions conséquentes ne soient exécutées.
Cette distinction est importante parce que les modèles de langage sont probabilistes. Le même système peut produire des réponses différentes à des entrées similaires, en particulier lorsqu’une tâche exige interprétation ou jugement. Les processus d’entreprise contiennent souvent des étapes où cette variabilité est acceptable et d’autres où elle ne l’est pas.
Thakrar sépare ces charges de travail en éléments déterministes et non déterministes. Les machines sont bien adaptées à des tâches telles que la lecture, l’organisation, le contrôle et la validation d’informations structurées. Le jugement, la synthèse et les décisions impliquant un contexte ambigu sont moins déterministes. Ces étapes exigent des contrôles plus stricts et, dans certains cas, une revue humaine.
L’architecture devrait refléter cette distinction. Une entreprise n’a pas besoin d’un modèle d’IA pour raisonner librement à travers chaque étape d’un workflow. Des règles métier fixes et des logiciels conventionnels peuvent gérer les étapes où l’action correcte est connue à l’avance. L’IA peut alors se concentrer sur les parties qui exigent réellement une interprétation. Cela réduit les appels de modèle inutiles et crée des points plus clairs pour les tests et le contrôle.
Selon Thakrar, des tests de benchmark ont montré qu’un modèle moins puissant doté d’un harness supérieur peut surpasser un modèle beaucoup plus grand fonctionnant avec un harness plus faible.
Le principe sous-jacent reste important pour la planification des dirigeants. Remplacer un modèle par un modèle plus récent peut améliorer un score de benchmark. Cela ne corrige pas automatiquement une récupération de données défaillante, des règles métier incorrectes, une mauvaise intégration des outils, des autorisations manquantes ou des workflows mal conçus. Ce sont des problèmes d’architecture.
Un harness bien conçu crée aussi un actif d’entreprise plus durable. Les modèles peuvent être changés à mesure que les prix et les capacités s’améliorent, tandis que l’entreprise conserve les workflows, le contexte, les contrôles et les intégrations système qu’elle a développés. Cela réduit l’importance stratégique de s’engager auprès d’un fournisseur de modèle unique.
La gouvernance appartient également à cette couche. Un agent capable de modifier un enregistrement client ou de déclencher un autre système introduit des risques différents de ceux d’un chatbot qui ne fait que générer du texte. Les entreprises ont besoin d’autorisations explicites, de règles de validation, de journaux d’audit et de chemins d’escalade. Les erreurs critiques doivent être interceptées avant qu’une action ne devienne difficile à annuler.
Pour la direction générale, la priorité d’investissement devrait donc aller au-delà de l’acquisition de modèles. La tâche d’ingénierie la plus importante consiste à construire l’infrastructure qui contrôle la manière dont les modèles reçoivent le contexte, utilisent les outils, prennent des décisions et passent à l’action. Les capacités des modèles continueront de s’améliorer. La qualité du système d’entreprise autour de ce modèle déterminera quelle part de cette capacité se transformera en valeur business fiable.
Le jugement humain a sa place aux points où l’IA fait face à une véritable ambiguïté
L’automatisation complète était le mauvais objectif pour l’agent de cartographie des parties prenantes de Zoho. Le système pouvait traiter rapidement les informations de réunion et les données externes, mais il peinait sur la partie de la tâche qui exigeait du jugement. Zoho a donc modifié le workflow au lieu de chercher à éliminer le rôle humain.
Ricky Thakrar, Head of Sales and Account Management chez Zoho, a décrit l’agent comme faisant partie du processus commercial de l’entreprise. Il utilise le contexte d’une première réunion client ainsi que des données enrichies tierces, comme un profil LinkedIn. Il évalue ensuite des probabilités et propose une cartographie des parties prenantes identifiant les personnes susceptibles d’influencer un achat.
L’objectif initial était une automatisation complète. « L’objectif initial était simplement d’éliminer complètement cette tâche du workflow humain », a déclaré Thakrar. L’agent créerait la cartographie des parties prenantes, l’enregistrerait et la laisserait prête pour l’équipe commerciale.
Le problème était la nuance. Les intitulés de poste n’ont pas une signification cohérente d’une entreprise à l’autre. Deux personnes ayant le même titre peuvent avoir une autorité, un contrôle budgétaire, une influence technique ou un accès aux décideurs seniors très différents. La dynamique des réunions peut fournir des informations supplémentaires difficiles à capturer dans des données structurées. Un commercial expérimenté peut reconnaître ces signaux parce qu’il comprend la conversation et l’organisation concernée.
Zoho aurait pu continuer à fournir davantage de données et d’instructions pour tenter d’automatiser ces jugements. À la place, l’entreprise a repensé le processus. L’IA produit une cartographie des parties prenantes proposée. Un humain la passe en revue, apporte des corrections et explique pourquoi ces changements sont nécessaires.
Cette répartition du travail préserve une grande partie du gain d’efficacité. Thakrar a indiqué que les cartographies produites par l’agent étaient généralement suffisamment proches pour faire gagner du temps aux employés. La revue humaine prend alors en charge l’ensemble plus restreint de décisions où le jugement contextuel compte le plus. Les corrections créent aussi un contexte plus riche qui peut améliorer les résultats ultérieurs de l’IA.
Pour les dirigeants, la question de conception importante n’est pas de savoir si un processus peut être entièrement automatisé. Elle est de savoir à quel moment l’incertitude devient significative pour l’entreprise. Une classification à faible confiance peut être acceptable si elle ne change que la manière dont l’information est organisée. Le même niveau d’incertitude peut être inacceptable lorsqu’un agent identifie un décideur clé, modifie un enregistrement client, approuve une transaction ou initie une action externe.
La revue humaine devrait donc être positionnée en fonction des conséquences et de l’incertitude. Les étapes déterministes avec des règles explicites sont de bons candidats à l’automatisation. Les décisions ambiguës ayant des conséquences commerciales, financières, juridiques ou réputationnelles significatives peuvent exiger une approbation ou une revue.
Cette approche fournit aussi un moyen pratique d’améliorer les agents. Les corrections humaines peuvent révéler des informations absentes du contexte initial, mettre au jour des schémas d’échec récurrents et identifier des règles métier qui devraient faire partie du système. L’organisation devrait capturer ce feedback de manière systématique plutôt que de traiter chaque correction comme un événement isolé.
Il existe aussi une contrainte managériale à prendre en compte. La supervision humaine a un coût. Exiger une approbation pour chaque action de l’IA peut supprimer une grande partie du gain de productivité, comme l’a montré l’expérience de Zoho avec son agent de churn. L’objectif est donc une intervention ciblée : automatiser le travail prévisible, identifier les incertitudes à forte valeur et demander aux personnes de se concentrer sur les décisions où leur jugement change le résultat.
Thakrar appelle cela un « human harness ». Pour la direction générale, la leçon plus large est claire. L’implication humaine devrait être une partie intentionnelle de l’architecture des agents. Les workflows les plus solides utilisent les personnes là où le jugement crée une valeur mesurable et utilisent l’automatisation partout ailleurs où elle peut être contrôlée de manière fiable.
La spécialisation transforme les expérimentations IA réussies en systèmes de production moins coûteux
Une fois qu’un agent peut exécuter de manière fiable une tâche étroite, continuer à utiliser un grand modèle généraliste peut devenir inutile. Le troisième pilier architectural de Zoho, la spécialisation, répond à ce problème de coût et de contrôle.
Thakrar définit la spécialisation comme le fait de faire passer en production un processus éprouvé d’un modèle de pointe vers un modèle plus petit et plus ciblé. Les modèles de pointe peuvent être utiles pendant le développement parce qu’ils offrent de larges capacités de raisonnement. Ils aident les équipes à établir si un workflow activé par l’IA peut fonctionner avant que les ingénieurs n’optimisent le système sous-jacent.
La production change l’économie du modèle. Une tâche d’entreprise stable peut s’exécuter des milliers ou des millions de fois. Une fois que ses entrées, ses sorties, ses exceptions et ses exigences de qualité sont comprises, une capacité de modèle large peut devenir une dépense qui apporte peu de valeur supplémentaire.
L’objectif est de capturer le jugement et la reconnaissance de schémas des experts métier dans un système plus focalisé. Thakrar préconise l’utilisation de modèles open-weight ou open-source que les entreprises peuvent entraîner ou affiner pour des charges de travail spécifiques et déployer dans leurs propres centres de données. Cela peut donner aux organisations un contrôle plus étroit sur le comportement du modèle, l’infrastructure et les informations sensibles de l’entreprise.
La spécialisation ne doit toutefois pas être interprétée comme l’obligation d’entraîner un modèle à partir de zéro pour chaque processus. Le fine-tuning, les instructions spécifiques à la tâche, la récupération du contexte d’entreprise, les règles déterministes et les modèles existants plus petits peuvent tous jouer des rôles différents. L’approche appropriée dépend du volume de la charge de travail, des exigences de performance, des coûts d’infrastructure, de la sensibilité des données et de la fréquence à laquelle la tâche évolue.
Il existe aussi un arbitrage opérationnel. Exécuter des modèles en interne peut offrir davantage de contrôle, mais cela transfère la responsabilité à l’entreprise. L’entreprise doit gérer l’infrastructure, le déploiement, la supervision, la sécurité, les mises à jour des modèles, l’évaluation et les compétences spécialisées. Pour certaines charges de travail, acheter de la capacité de modèle auprès d’un fournisseur externe peut rester plus économique. La propriété ne crée de valeur que lorsque la charge de travail et l’importance stratégique justifient la charge opérationnelle supplémentaire.
Thakrar met particulièrement l’accent sur la couche d’orchestration parce qu’elle contient les workflows et les connaissances accumulées de l’entreprise. « Le véritable pari de l’entreprise consiste à garder cette couche d’orchestration, qui est votre propriété intellectuelle et votre savoir, en interne », a-t-il déclaré. Il a également soutenu que les entreprises devraient viser à « exécuter, entraîner et héberger leurs propres modèles ».
Les dirigeants devraient distinguer cette recommandation stratégique d’une exigence universelle. Les petites entreprises, les charges de travail à faible volume et les applications qui évoluent rapidement peuvent favoriser les services managés. Les charges de travail à fort volume ou sensibles peuvent justifier davantage un contrôle interne renforcé.
Le point le plus durable est la propriété de la connaissance métier. Le contexte client, la logique des processus, les corrections des experts, les règles de validation et la conception des workflows peuvent être plus spécifiques à l’entreprise que le modèle sous-jacent. Préserver le contrôle de ces actifs réduit le risque que la capacité IA d’une organisation devienne indissociable d’un fournisseur de modèle externe.
La spécialisation peut donc servir trois objectifs : réduire les coûts d’inférence, accroître le contrôle opérationnel et conserver la connaissance d’entreprise. Elle a le plus de valeur après qu’un workflow a été prouvé et mesuré. Établissez d’abord que l’agent effectue un travail utile. Déterminez ensuite quelle capacité de modèle ce travail exige réellement. Le système de production peut être optimisé à partir de ces éléments probants plutôt qu’à partir de l’hypothèse qu’un modèle plus grand est toujours meilleur.
Le routage, le harness et la spécialisation forment une architecture pratique pour l’IA d’entreprise
Les performances de l’IA d’entreprise ne sont pas déterminées par le seul modèle. L’expérience de Zoho met en évidence trois contrôles architecturaux qui comptent davantage en production : le routage, le harness et la spécialisation. Ensemble, ils déterminent quel modèle traite une tâche, quel contexte et quels contrôles l’entourent, et si une charge de travail éprouvée doit continuer à utiliser un modèle généraliste coûteux.
Ricky Thakrar, Head of Sales and Account Management chez Zoho, soutient que des systèmes contraints et riches en contexte peuvent surpasser des modèles coûteux ajoutés à des processus d’entreprise fragmentés. Sa position découle directement de l’expérience de Zoho avec ses propres agents. Un modèle performant ne pouvait pas compenser l’absence de contexte client dans le workflow de churn. Une architecture plus complète était nécessaire.
Le routage est le premier contrôle. Il envoie chaque charge de travail vers un modèle adapté à sa complexité. Les tâches de routine peuvent s’exécuter sur des modèles plus petits, tandis que les requêtes difficiles ou incertaines peuvent être transférées vers des systèmes plus performants. Cela compte sur le plan financier. Thakrar a indiqué que Zoho a observé chez certains clients des cas où un modèle de 3 milliards de paramètres pouvait réduire les coûts jusqu’à 95 %. Il a également averti qu’une utilisation indiscriminée des modèles de pointe peut consommer en quelques mois un budget annuel de tokens planifié.
Le chiffre de 95 % ne doit pas être considéré comme une économie valable pour l’ensemble du secteur. Les entreprises devraient tester la précision, la latence, les taux d’échec et le coût total avant de décider où les modèles plus petits sont appropriés.
Le deuxième contrôle est le harness, également appelé couche d’orchestration. Il relie le modèle aux données d’entreprise, à la mémoire, aux outils logiciels, aux garde-fous et aux systèmes d’exécution. Il détermine aussi quelles parties d’un processus sont gérées par des règles fixes, lesquelles exigent un raisonnement de l’IA et à quels endroits une approbation humaine est nécessaire.
Cette couche est critique pour l’IA agentique parce que les agents peuvent passer à l’action. Un système qui modifie des enregistrements CRM, envoie des communications ou déclenche une autre application exige des contrôles plus stricts qu’un système qui se contente de rédiger du texte. Les autorisations, la validation, la journalisation, l’escalade et la revue humaine doivent donc être conçues dans le workflow avant le déploiement.
La spécialisation est le troisième contrôle. Une fois qu’un agent a démontré qu’il peut exécuter une tâche définie de manière fiable, l’organisation peut évaluer si la charge de travail a encore besoin d’un modèle de pointe. Un modèle plus petit, focalisé sur la tâche, peut offrir les performances requises à moindre coût. Les entreprises peuvent aussi affiner ou exploiter des modèles autour de leurs propres données, processus et connaissances expertes lorsque l’économie et les exigences de sécurité le justifient.
Thakrar relie la spécialisation à la propriété intellectuelle. « Le véritable pari de l’entreprise consiste à garder cette couche d’orchestration, qui est votre propriété intellectuelle et votre savoir, en interne », a-t-il déclaré. Sa position est que les entreprises devraient à terme chercher à acquérir la capacité d’exécuter, d’entraîner et d’héberger leurs propres modèles.
Cette recommandation exige un business case. L’auto-hébergement peut améliorer le contrôle des données, du déploiement et du comportement du modèle, mais il crée aussi des coûts d’infrastructure, de sécurité, de supervision et de talents. Les modèles managés peuvent rester le meilleur choix pour de nombreuses charges de travail. Ce qui compte sur le plan stratégique, c’est de conserver le contrôle du contexte, des règles, des évaluations et des workflows spécifiques à l’entreprise qui déterminent la manière dont les modèles sont utilisés.
Les trois piliers créent aussi une séquence opérationnelle claire. D’abord, donner au système suffisamment de contexte pour comprendre la tâche. Ensuite, router la tâche vers le modèle le moins coûteux capable d’atteindre les performances requises. Utiliser le harness pour contraindre l’exécution, valider les résultats importants et introduire le jugement humain là où l’incertitude a des conséquences significatives. Une fois le processus stabilisé, évaluer si la spécialisation peut réduire les coûts ou accroître le contrôle.
Cela change ce que la direction générale devrait mesurer. Les scores de benchmark des modèles ne suffisent pas. Les dirigeants ont besoin de mesures au niveau des charges de travail sur le coût, la précision, la latence, la revue humaine, les taux d’erreur et la réussite effective des tâches. Ils devraient aussi suivre si les agents suppriment réellement du travail. L’expérience de Zoho avec son agent de churn a montré pourquoi : un agent peut techniquement générer le résultat requis alors que les employés refont encore ses recherches parce qu’ils ne lui font pas confiance.
L’avantage stratégique réside donc de plus en plus dans la conception du système. Les modèles continueront de s’améliorer et de devenir plus interchangeables pour de nombreuses tâches. Le contexte d’entreprise, la conception des workflows, le feedback humain, les règles de validation et le savoir opérationnel sont plus difficiles à reproduire.
C’est la logique centrale derrière la position « plus petite, plus intelligente, plus sûre » de Zoho. Utiliser la capacité du modèle de manière sélective. Mettre l’intelligence d’entreprise dans l’architecture environnante. Vérifier les décisions conséquentes avant qu’elles ne deviennent des actions. Le routage, le harness et la spécialisation fournissent la structure technique permettant de mettre ces principes en production.
Récapitulatif
La contrainte de l’IA d’entreprise n’est plus l’accès à des modèles puissants. C’est la capacité à transformer ces modèles en systèmes fiables. Davantage de paramètres ne peuvent pas corriger un contexte métier manquant, des workflows faibles, des contrôles insuffisants ou des employés qui ne font pas confiance au résultat.
Cela change la priorité d’investissement. Construisez d’abord la couche de contexte. Routez chaque charge de travail vers le modèle le moins coûteux qui répond à ses exigences. Placez la validation, les autorisations et le jugement humain aux points où les erreurs ont de vraies conséquences. Une fois qu’une charge de travail est éprouvée, déterminez si un modèle plus petit et spécialisé peut l’exécuter à moindre coût.
Les dirigeants devraient aussi mesurer des résultats au-delà de la précision du modèle. Suivez le coût par tâche accomplie, les taux d’erreur et d’escalade, le temps de vérification humaine, la latence et le travail réellement supprimé du processus. Un agent qui produit une réponse mais oblige les employés à tout revérifier n’a pas apporté d’automatisation significative.
L’actif durable est la connaissance d’entreprise qui entoure le modèle. Le contexte client, les règles métier, les workflows, les corrections des experts et l’orchestration sont spécifiques à l’entreprise. Les modèles changeront. Les fournisseurs changeront. Cette connaissance institutionnelle devrait rester sous le contrôle de l’entreprise.
L’objectif n’est pas une capacité IA maximale dans chaque workflow. C’est une capacité suffisante, fournie avec le bon contexte et gouvernée par la bonne architecture. C’est ainsi que l’IA agentique devient plus petite, plus intelligente, plus sûre et plus utile à l’entreprise.
Un projet en tête ?
Planifiez un appel de 30 minutes avec nous.
Des experts senior pour vous aider à avancer plus vite : produit, tech, cloud & IA.


