Comment mieux maîtriser les coûts de l’IA en entreprise

L’augmentation de l’usage de l’IA et la baisse des dépenses en tokens n’indiquent guère à un CTO si l’IA crée réellement de la valeur. Uber a mis le problème en évidence de façon frappante : en décembre 2025, l’entreprise a donné Claude Code à ses ingénieurs et créé des classements internes des équipes selon leur consommation de tokens, mais dès avril, l’intégralité de son budget 2026 consacré au codage par IA était épuisée. Andrew Macdonald, président et COO d’Uber, a déclaré que l’entreprise n’avait toujours pas démontré de lien entre un usage intensif et de meilleurs produits pour les passagers et les chauffeurs.

Ce décalage a désormais un nom : le « tokenmaxxing », soit une hausse rapide de la consommation de tokens sans retour sur investissement correspondant. L’enjeu financier grandit, car Gartner prévoit que les dépenses en logiciels d’agents IA approcheront 207 milliards de dollars cette année, en hausse de plus de 139 % par rapport aux 86,4 milliards de dollars de 2025. L’adoption et la consommation sont des intrants ; les résultats attendus en entreprise sont des fonctionnalités livrées, des bugs corrigés, des problèmes clients résolus et d’autres travaux utiles dont la valeur peut justifier la dépense.

Ces résultats sont difficiles à comparer aux dépenses, car le coût des tokens varie selon le travail effectué. Le même ingénieur utilisant le même outil le même jour peut générer des coûts radicalement différents lorsqu’une tâche relève de l’autocomplétion et qu’une autre mobilise des agents parallèles sur une migration majeure de base de données. La gouvernance d’entreprise doit donc répondre simultanément à deux questions : où les dépenses peuvent être rendues plus efficaces, et quelles charges de travail produisent des résultats qui valent d’être financés au départ.

La valeur de l’IA exige des mesures de résultats

L’expérience d’Uber montre pourquoi les métriques d’adoption deviennent dangereuses lorsqu’elles véhiculent un jugement implicite sur la valeur. Un classement fondé sur la consommation récompense un intrant observable, alors que l’entreprise a finalement besoin de résultats d’ingénierie. Une adoption quasi universelle de l’IA peut coexister avec peu d’amélioration dans la livraison, tandis qu’une charge de travail très consommatrice de tokens peut être hautement productive. La consommation seule ne permet pas de distinguer ces cas.

Puisque la consommation ne permet pas d’établir la valeur, la gouvernance doit inclure l’allocation et les résultats. Les dirigeants doivent de plus en plus décider où des modèles coûteux et des workflows agentiques méritent le budget, tout en établissant des preuves que le travail produit a une réelle importance. Les mécanismes d’optimisation des coûts sont déjà suffisamment sophistiqués pour automatiser certaines décisions d’allocation. Mesurer le retour business reste plus difficile.

Les plafonds servent des objectifs de gouvernance différents

Ce problème d’allocation a déjà modifié la manière dont les entreprises contrôlent la consommation. Le contrôle immédiat d’Uber est concret : les dépenses sont désormais plafonnées à 1 500 dollars par employé, par outil de codage agentique, chaque mois. Microsoft a remis en question le coût des licences Claude Code et a annulé des licences dans l’ensemble de sa division Experiences and Devices, tandis que Duolingo a abandonné un projet consistant à intégrer l’usage de l’IA dans les évaluations de performance après que des employés ont contesté le fait d’être poussés à utiliser les outils pour eux-mêmes.

Un plafond peut aussi servir de signal plutôt que de simple rationnement. Everlaw, qui fournit de l’IA pour les contentieux et les enquêtes et a donc un intérêt commercial dans un usage efficace de l’IA en entreprise, fixe des limites de tokens par personne, mais son CTO Max Christoff les utilise comme signaux d’escalade. Lorsqu’un ingénieur atteint le seuil, un e-mail d’une ligne est envoyé à l’équipe outils, et l’ingénieur reçoit généralement le double de son quota le jour même. L’événement crée de la visibilité et une opportunité de revue sans supposer qu’une forte consommation soit indésirable.

Agiloft, une plateforme de gestion du cycle de vie des contrats en entreprise ayant elle aussi un intérêt commercial dans les logiciels d’entreprise activés par l’IA, est allée plus loin et a supprimé ses plafonds. Noe Ramos, son vice-président des opérations IA, a expliqué cette décision : « 74 % des personnes n’atteignaient de toute façon jamais les anciens plafonds. Les plafonds constituaient un faux plafond qui créait des frictions pour les gros utilisateurs sans traiter les véritables moteurs de coût. » Pour Agiloft, la restriction affectait la minorité ayant les charges de travail les plus importantes tout en faisant peu pour la manière dont le système sous-jacent sélectionnait les modèles.

Ces usages différents rendent la « gouvernance des coûts » imprécise, à moins que les dirigeants ne précisent ce qu’un contrôle doit accomplir. Uber utilise une limite mensuelle fixe ; Everlaw utilise un seuil pour déclencher une attention particulière puis augmente facilement le quota ; Agiloft a décidé que ses limites gênaient certains utilisateurs plus intensifs tout en laissant intact le mécanisme de dépense sous-jacent. Comme un travail à forte consommation de tokens peut être légitime, une entreprise peut approuver des budgets plus élevés, laisser les individus choisir les modèles ou acheminer automatiquement les requêtes via l’infrastructure.

Le gaspillage évident peut être éliminé avant même de connaître pleinement le ROI

Une fois que la gouvernance distingue l’usage intensif légitime des dépenses évitables, l’infrastructure devient une cible immédiate. Ramos voit dans les choix d’infrastructure une source de gaspillage. « Les équipes ne brûlent pas du budget parce qu’elles aiment le gaspillage. Elles le brûlent parce que l’infrastructure par défaut les y pousse », a-t-il déclaré. « La plupart des entreprises laissent encore la sélection du modèle à la personne qui rédige le prompt, ce qui signifie qu’un modèle frontier traite des tâches qu’un modèle open-weight bon marché pourrait faire tout aussi bien. Ce n’est pas un problème humain. C’est un problème de plomberie. »

Promova, une entreprise d’apprentissage des langues, a rencontré ce problème dans les paramètres par défaut fournis aux employés. Le responsable de l’ingénierie Dmytro Palaniichuk a constaté que des modèles premium étaient déjà sélectionnés dans les offres équipe et entreprise, avec un effort de raisonnement élevé activé par défaut. Dans l’offre de Promova, les sessions Opus passaient également à une fenêtre de contexte de 1 million de tokens, et les employés laissaient généralement ces paramètres inchangés. En quelques mois, Palaniichuk a vu des modèles premium utilisés pour des tâches simples comme la vérification des e-mails.

Ces paramètres par défaut concentraient les dépenses de Promova : Opus utilisant la fenêtre de 1 million de tokens représentait environ un tiers de sa dépense mensuelle. Promova travaille vers la répartition de modèles suivante, même si Palaniichuk considère cette allocation comme une direction plutôt qu’une configuration permanente.

L’objectif fait de la sélection des modèles une composante de l’allocation des coûts en adaptant le modèle au travail. Changer le paramètre par défaut laisse toutefois les habitudes des employés dans la boucle. « Ce qui freine notre progression est surtout un problème comportemental. Même si vous imposez Sonnet comme modèle par défaut dans l’organisation, si vous ne sensibilisez pas à quoi utiliser et quand, les gens retombent dans leurs habitudes », a déclaré Palaniichuk. Selon lui, les employés doivent comprendre quel modèle convient à quelle tâche et prendre l’habitude de vérifier ce choix avant d’ouvrir une nouvelle conversation avec un LLM.

Agiloft a déplacé une plus grande part de cette même décision vers l’infrastructure. L’entreprise a fait des modèles moins chers le choix par défaut, passe à des modèles frontier lorsque nécessaire, route au niveau de l’infrastructure au lieu de laisser le routage dans les prompts individuels, et utilise le caching. Ramos considère qu’une passerelle LLM à l’échelle de l’entreprise, c’est-à-dire le service par lequel transitent les requêtes vers les modèles afin que les politiques puissent être appliquées de manière centralisée, constitue l’amélioration initiale la plus rapide pour de nombreuses entreprises : « Le gain le plus rapide pour la plupart des équipes en entreprise, c’est une passerelle LLM à l’échelle de l’entreprise qui gère des choix par défaut moins coûteux et un routage intelligent. »

Cette approche conduit Ramos à une conclusion architecturale plus forte : « Ne rationnez pas l’outil. Corrigez l’architecture sous-jacente. La gouvernance par la rareté est un pansement. Le routage intelligent est la solution. » Merge, Databricks, AWS Bedrock et Azure AI Foundry de Microsoft sont des offres d’infrastructure concurrentes avec des approches d’auto-routage conçues pour faire correspondre la complexité de la tâche à un modèle approprié à un coût abordable. Ces fournisseurs ont un intérêt commercial à une adoption plus large des infrastructures de routage, tandis que le mécanisme opérationnel qu’ils exposent déplace davantage de décisions coût-performance hors des mains des utilisateurs individuels.

Databricks montre à quel point ce mécanisme peut devenir détaillé. Lors de son Data + AI Summit en juin, l’entreprise a présenté Smart Routing dans Unity Gateway, aux côtés de plafonds de dépenses stricts et d’une attribution des coûts couvrant les modèles hébergés, les agents de codage et les agents personnalisés. Smart Routing est en bêta et prend en charge à la fois des modes de recommandation seule et de routage automatique, permettant à une organisation de choisir si le système conseille un utilisateur ou prend lui-même la décision de routage. Databricks commercialise cette infrastructure de gouvernance et en tire donc un bénéfice lorsque les entreprises adoptent un routage centralisé.

David Nasi, directeur de la gestion produit chez Databricks, explique que Smart Routing évalue chaque requête à l’aide de signaux déterministes et d’une classification fondée sur des modèles. Ses entrées incluent l’intention et la longueur du prompt, les fichiers référencés, les stack traces, l’ampleur du changement, la profondeur de raisonnement requise et la complexité d’exécution. Ensemble, ces signaux décrivent les exigences probables d’une tâche avant que la plateforme ne s’engage sur un modèle et le coût associé.

Le choix du modèle n’est qu’une partie de cette allocation, car la configuration d’exécution environnante affecte aussi les résultats. Un harness est le logiciel et la configuration qui contrôlent la manière dont un modèle est invoqué et reçoit des outils ou du contexte, et Databricks peut le sélectionner ou le configurer pendant le routage. « Nous avons constaté qu’un même modèle se comporte différemment lorsqu’il est exploité avec un harness différent, c’est pourquoi nous avons conçu Smart Routing avec cette flexibilité », a déclaré Nasi. L’unité d’optimisation pertinente peut donc inclure le modèle sous-jacent et la manière dont il est exécuté.

Comme l’allocation automatisée crée une couche de décision supplémentaire, les administrateurs doivent aussi pouvoir inspecter ce que fait cette couche. Databricks expose la décision à l’exécution afin que les administrateurs puissent voir pourquoi le routage a eu lieu. « La décision est totalement transparente à l’exécution ; nous évitons explicitement de faire du routeur une boîte noire », a déclaré Nasi. Lorsque les dépenses atteignent un plafond budgétaire, un administrateur peut bloquer les requêtes supplémentaires avec une limite stricte ou configurer un repli qui essaie d’abord un modèle moins cher répondant malgré tout aux exigences applicables.

Les agents rendent ce contrôle plus difficile, car une tâche demandée peut déclencher des dizaines d’appels au modèle sans qu’une personne approuve chacun d’eux. Une décision par appel peut donc être trop étroite par rapport à l’unité réelle de travail. Databricks gère ces charges de travail en évaluant aux frontières d’exécution, c’est-à-dire aux points où une étape significative du travail de l’agent commence ou se termine, afin que la décision de routage corresponde davantage à la tâche plus large.

Les premiers usages chez Databricks suggèrent que ce type d’optimisation peut éliminer des surallocations manifestes. Les équipes qui envoyaient auparavant tout vers des modèles frontier déplacent désormais la génération de boilerplate, les corrections de bugs simples et les modifications mineures vers des modèles moins chers sans détérioration mesurable des taux de résolution, selon Nasi. Ces décalages peuvent être corrigés avant même qu’une entreprise ne dispose d’un modèle complet du ROI business, laissant la question plus difficile de la valeur à une couche distincte de gouvernance.

Le ROI exige de mesurer le travail lui-même

Everlaw montre pourquoi cette question de valeur subsiste même après l’amélioration de l’allocation des coûts. Ses projets d’ingénierie quantifiés mettent les dépenses en tokens en regard de l’effort d’implémentation estimé :

Le premier cas donne à Christoff un retour concret à l’aune duquel juger les dépenses en tokens. « Ce sont des chiffres réels ; un ROI de 3 500 dollars pour économiser sept mois de temps d’ingénierie, c’est tout simplement une évidence », a déclaré Christoff. Le produit non lancé applique le même raisonnement à une dépense plus importante : sa facture de tokens est substantielle, mais la réduction estimée de l’effort d’ingénierie change la signification de cette dépense.

Everlaw a aussi constaté que certaines dépenses ne produisaient pas de travail exploitable. L’entreprise a dépensé des milliers de dollars pour faire porter par des agents du code d’interface de Dojo vers React, puis a abandonné la sortie générée parce que les deux frameworks reposent sur des hypothèses différentes quant à la relation entre l’état et la vue. L’équipe a revu le processus afin que les agents documentent d’abord le comportement du système legacy, après quoi l’implémentation peut avancer à partir de cette documentation comportementale.

Ensemble, les cas Everlaw établissent une unité plus utile pour la gouvernance : le résultat utile rapporté à la dépense. Une facture de tokens importante peut accompagner une réduction majeure du temps d’implémentation, tandis qu’une autre facture de plusieurs milliers de dollars peut se terminer par du code jeté. La consommation brute ne permet pas à un manager de savoir quelle situation se produit, et réduire le coût par appel ne peut pas rendre utile un travail abandonné.

Rick Spencer, GM technology and product chez SUSE, fait le même constat à travers une relation hypothétique entre coût et retour. En tant que dirigeant d’un éditeur de logiciels évaluant la productivité du développement piloté par l’IA, Spencer a un intérêt commercial et opérationnel dans l’efficacité d’utilisation de tels outils. « La première réaction ne devrait pas être de “moins utiliser l’IA”. Une forte consommation de tokens peut vouloir dire beaucoup de choses différentes. Si quelqu’un utilise 16 000 dollars de tokens pour nous faire économiser 100 000 dollars, bien sûr que nous voulons l’encourager. » Sa règle opérationnelle en découle directement : « Tout commence par le diagnostic, pas par l’application de règles. »

Ce diagnostic commence par l’identification du type de travail qui consomme les tokens. SUSE organise l’usage en trois catégories que les managers utilisent pour accompagner les équipes : travail quotidien, agents autonomes et Curve Jumping, cette dernière couvrant les efforts stratégiques ponctuels. Catégoriser la charge de travail donne aux managers une raison d’examiner ce que fait un modèle avant d’évaluer sa consommation. Spencer souligne également que le meilleur modèle pour un agent autonome peut différer du dernier modèle frontier, de sorte qu’une charge de travail précieuse peut encore offrir des possibilités d’exécution moins coûteuse.

Ces catégories soutiennent l’objectif plus large de SUSE. « Le changement important, c’est que nous n’essayons pas de supprimer l’usage ; nous essayons de nous assurer que l’usage se traduit par un impact », a déclaré Spencer. SUSE ne dispose actuellement d’aucun proxy de routage automatisé, laissant ces décisions de modèle aux développeurs individuels, même si un proxy figure sur sa feuille de route. Ses preuves de valeur sont pour l’instant anecdotiques plutôt qu’exprimées au moyen de métriques de ROI de l’IA quantitatives.

Ces anecdotes montrent les types de résultats qu’un système d’évaluation devra finalement capturer. Un projet SUSE a réduit à zéro des centaines de CVE de dépendances, Common Vulnerabilities and Exposures. Depuis mai, ses agents ont également catégorisé près de 10 000 CVE dans la base de données VEX. Des résultats comme ceux-ci donnent aux managers un résultat qu’ils peuvent mettre en relation avec la dépense en IA.

Promova montre pourquoi établir cette relation peut rester difficile : l’optimisation est souvent déployée en même temps que d’autres travaux sans lien. Palaniichuk a pu identifier la part importante de la dépense mensuelle associée à une configuration particulière de modèle premium, mais il n’a pas pu isoler un chiffre clair d’économies avant/après, car les changements de routage et de modèle ont eu lieu en même temps que d’autres changements. La télémétrie des coûts peut révéler une cible d’intervention, tandis que des changements simultanés rendent plus difficile l’isolement de l’effet propre de cette intervention.

Databricks construit une instrumentation visant à combler une partie de cet écart. Unity Gateway inclut un tracing unifié, des frameworks d’évaluation LLM-as-a-judge, des jeux de données d’évaluation, des analyses de traces et des boucles de feedback automatisées. Ces outils peuvent aider une équipe à observer les requêtes, comparer les résultats générés et détecter les changements de qualité après modification du routage. Pour Databricks, ces capacités font aussi partie de la plateforme commerciale de gouvernance qu’elle vend aux entreprises.

L’évaluation rend l’optimisation des coûts plus mesurable, mais l’exactitude métier reste de la responsabilité du client. Palaniichuk décrit le problème de maintenance : « vous imposez des contrôles déterministes à une sortie non déterministe, et les modèles évoluent à un rythme d’environ un trimestre ; une évaluation réglée sur un modèle ne se transfère pas proprement au suivant. » La couche d’évaluation évolue donc avec les systèmes qu’elle évalue, transformant la gouvernance en activité d’ingénierie continue.

Réussir une évaluation laisse encore une autre préoccupation d’ingénierie, car le code généré a une durée de vie utile après l’exécution des tests. Les tests peuvent réussir alors que l’implémentation reste difficile à maintenir pour les ingénieurs. Christoff décrit un schéma d’échec récurrent : « L’agent de codage proposera vingt correctifs de surface au lieu de traiter un motif sous-jacent. » Une sortie techniquement acceptée peut donc imposer des coûts d’ingénierie futurs qu’un test de correction de base ne détecte pas.

Comme la maintenabilité et la qualité architecturale exigent un contexte local, Everlaw donne aux ingénieurs un large choix de modèles et un budget en dollars après que les modèles ont passé la revue de sécurité. L’ingénieur qui examine le code généré peut alors développer un jugement pratique sur le modèle qui tend à produire un travail qui mérite d’être conservé. Cette méthode préserve une marge d’appréciation locale là où un routeur ou un test automatisé peut manquer de contexte.

Cette frontière compte parce que l’automatisation résout un problème plus étroit que le ROI. Le routage peut attribuer des ressources moins chères, les paramètres par défaut peuvent supprimer une consommation premium accidentelle, les plafonds peuvent imposer ou rendre visibles des limites budgétaires, et un choix conscient du modèle peut améliorer les décisions individuelles. Déterminer si le travail demandé a créé de la valeur business exige des preuves de résultats du type de celles qu’Everlaw peut exprimer en temps d’ingénierie et que d’autres équipes apprennent encore à isoler.

Une gouvernance durable combine infrastructure, comportement, télémétrie et jugement

Comme l’allocation des coûts et la mesure de la valeur opèrent à des niveaux différents, c’est surtout sur le point de départ qu’il existe des désaccords entre praticiens. Ramos commence par le routage centralisé, car les paramètres par défaut et l’architecture peuvent provoquer des dépenses inutiles avant même qu’un utilisateur ne fasse un choix significatif. Spencer commence par l’accompagnement des développeurs et la formation des managers au diagnostic des types d’usage. Christoff remonte encore plus en amont en demandant ce que l’entreprise cherche à optimiser avant de choisir une intervention, tandis que Palaniichuk commence par observer ce que font réellement les équipes et par identifier des opportunités précises.

Le processus de découverte de Palaniichuk donne aux équipes des outils et des budgets visibles pour expérimenter avec différents modèles et fournisseurs. L’organisation capture ensuite l’usage réel sur une courte période via la télémétrie et crée une boucle de feedback autour des résultats. Les équipes utilisent leurs propres données de consommation pour trouver une allocation appropriée au fil de leur travail, et Palaniichuk avertit également que la sophistication technique ne prédit pas nécessairement la discipline de dépense.

Ces observations expliquent pourquoi l’infrastructure et le comportement peuvent nécessiter des contrôles distincts. Ramos situe une grande partie des coûts évitables majeurs dans la plomberie sous-jacente, tandis que Palaniichuk constate que les habitudes persistent après le changement des paramètres par défaut. SUSE s’appuie actuellement sur le discernement de développeurs accompagnés, et Everlaw laisse aux ingénieurs le choix du modèle dans des budgets en dollars visibles. Comme ces approches gouvernent des points de décision différents, une entreprise peut en appliquer plusieurs à mesure qu’elle apprend d’où viennent réellement ses dépenses et sa valeur.

L’objectif de répartition des modèles chez Promova illustre pourquoi la discipline de gouvernance doit survivre aux changements de modèles individuels. « Je ne pense pas que cet objectif précis comptera beaucoup, mais la discipline, elle, comptera », a déclaré Palaniichuk. Les modèles moins chers continueront de modifier l’économie disponible, tandis qu’un choix croissant de modèles accroît le besoin de décider quel outil convient à une tâche donnée. Christoff s’attend de la même manière à ce que les tactiques d’optimisation spécifiques d’aujourd’hui expirent, alors même que la discipline qui les sous-tend perdurera.

Cet environnement changeant fait de l’optimisation des coûts et de la validation de la valeur deux activités parallèles. Une entreprise peut corriger un paramètre par défaut coûteux, router un travail simple vers un modèle moins cher ou signaler immédiatement un événement budgétaire inhabituel, car ces actions ne nécessitent pas une attribution complète du ROI. En parallèle, la télémétrie, l’évaluation, la revue de code, les mesures de résultats et les business cases peuvent accumuler des preuves que le travail produit mérite la dépense. Une allocation efficace importe lorsque le résultat reste digne d’être produit.

Les budgets de tokens pourraient devenir une catégorie de planification business

Une fois les dépenses en tokens liées aux résultats, le prochain changement pourrait être organisationnel. Christoff prévoit qu’au cours des un à deux prochaines années, les dépenses en tokens seront de plus en plus traitées comme les effectifs annuels ou les coûts de production, et moins comme des dépenses générales de logiciels ou d’IT. Les responsables de département entreraient dans la planification annuelle avec une position à la fois sur les effectifs et sur les tokens, étayée par un business case pour chacun.

Ce modèle de planification permet des réponses très différentes selon les équipes. Un département pourrait rationnellement demander des millions de dollars en tokens tout en ajoutant presque aucun employé ; un autre pourrait faire le choix inverse. Le budget qui en résulterait exprimerait la manière dont le département entend produire des résultats business, faisant de la capacité en tokens une composante du plan opérationnel aux côtés des personnes censées l’utiliser.

Points clés à retenir

• Liez les dépenses d’IA aux résultats : les CTO ont besoin de mesures telles que le temps d’ingénierie économisé, le travail utile livré, les bugs corrigés et les problèmes clients résolus pour déterminer si la hausse de la consommation de tokens crée de la valeur business.
• Adaptez les plafonds à l’objectif de gouvernance : des limites fixes peuvent contenir les dépenses, tandis que des seuils d’escalade peuvent faire remonter des usages inhabituels pour examen. Les organisations doivent décider si un plafond vise à restreindre la consommation, à déclencher un contrôle ou à soutenir l’allocation budgétaire.
• Éliminez le gaspillage induit par l’infrastructure : les équipes plateforme peuvent utiliser des choix par défaut moins coûteux, des passerelles LLM centralisées, le caching et un routage intelligent pour faire correspondre le coût du modèle à la complexité de la tâche. Un routage transparent et des politiques de repli aident à préserver la supervision à mesure que ces décisions s’automatisent.
• Mesurez le travail produit par l’IA : les responsables de l’ingénierie et du métier doivent relier la dépense en tokens à des résultats tels que le temps gagné, les problèmes de sécurité résolus et le code exploitable livré. L’évaluation, la télémétrie et la revue de code peuvent révéler des charges de travail qui consomment des ressources importantes sans produire de valeur durable.
• Combinez infrastructure, comportement, télémétrie et jugement : la gouvernance de l’IA doit évoluer à mesure que changent les modèles, les prix et les habitudes des employés. Le routage centralisé peut corriger des paramètres par défaut inefficaces, tandis que la formation, les budgets visibles, l’évaluation et le jugement local des ingénieurs couvrent les décisions que l’infrastructure ne peut pas prendre seule.
• Traitez la capacité en tokens comme une ressource opérationnelle : les responsables de département peuvent de plus en plus planifier les budgets de tokens aux côtés des effectifs et des coûts de production, avec des business cases liés aux résultats attendus. Cela permet aux équipes fortement consommatrices d’IA de justifier une consommation plus élevée lorsque l’économie le permet.