Il existe un concept qui commence à prendre forme dans l’industrie hôtelière : le language tax — un « impôt silencieux » que vous payez chaque fois que vous interagissez avec un LLM (un grand modèle de langage capable de comprendre et de générer du langage humain à grande échelle) dans une langue autre que l’anglais. Et il ne s’agit pas de quelque chose de théorique ou de marginal. Il s’agit d’un coût réel, mesurable, qui s’accumule mois après mois pour les équipes qui ont déjà intégré l’IA dans leurs opérations quotidiennes.

Les grands modèles de langage — GPT, Claude, Gemini, Llama — traitent le texte à l’aide de tokeniseurs. Ces tokeniseurs découpent les mots en unités plus petites avant le traitement. Le problème est qu’ils ont été entraînés majoritairement sur des textes en anglais, ce qui les rend nettement plus efficaces dans cette langue. Lorsque vous écrivez en espagnol, en français ou en allemand, le modèle a besoin de plus de tokens pour traiter exactement le même contenu. Plus de tokens = un coût plus élevé.

 

Le cas de Claude : le multiplicateur le plus élevé du marché

Parmi tous les fournisseurs analysés, celui qui présente le plus mauvais ratio d’efficacité linguistique est Anthropic avec son modèle Claude, qui affiche un multiplicateur moyen de 2,07× pour l’espagnol par rapport à l’anglais. Concrètement : si vous écrivez à Claude en espagnol, vous payez — en moyenne — plus du double de tokens que si vous lui adressiez exactement le même contenu en anglais.

Pour une équipe qui utilise Claude de manière occasionnelle, l’impact est négligeable. Mais pour un service de revenue management ou de marketing qui travaille quotidiennement avec l’IA — interprétation de rapports de pick‑up, génération de réponses aux avis, automatisation des communications avec les OTA ou analyse des données de demande — ce multiplicateur devient une ligne de coût que personne n’a validée dans le budget et que très peu ont identifiée.

 

S’il s’agit d’un projet mené à 100 % en espagnol, faut‑il rédiger les prompts en anglais ?

La réponse courte est : cela dépend de ce que vous cherchez à optimiser. Si le projet est en espagnol — l’équipe travaille en espagnol, les documents sont en espagnol et le livrable final est en espagnol — passer à l’anglais uniquement pour économiser des tokens introduit de vraies frictions : un risque accru d’erreurs de traduction, une perte de contexte et des cycles de relecture supplémentaires. Ce coût opérationnel peut facilement dépasser les économies réalisées sur les tokens.

Le language tax devient réellement pertinent surtout lorsque le volume d’utilisation est très élevé et que l’anglais est une langue de travail viable. Pour la majorité des équipes hôtelières en Espagne, ce n’est pas le cas. Ce qui vaut vraiment la peine, c’est de comprendre ce coût avant de prendre une décision — pas nécessairement de passer à l’anglais. La conclusion pratique n’est pas « écrivez à l’IA en anglais », mais plutôt « choisissez le fournisseur et le modèle de manière éclairée, en sachant ce que chacun vous coûte dans votre propre langue ».

 

 

Que signifie tout cela pour le secteur hôtelier, et pourquoi est‑ce crucial ?

Les équipes de revenue et de marketing sont depuis des années les early adopters de la technologie dans l’hôtellerie. Les équipes de revenue ont été les premières à intégrer des solutions de RMS, les premières à connecter les PMS à des outils de tarification dynamique, et sont aujourd’hui parmi les premières à intégrer des flux de travail basés sur l’IA générative. De leur côté, les départements marketing et e‑commerce ont été les premiers à intégrer les réseaux sociaux dans la stratégie hôtelière, à créer et gérer des sites web via des CMS, à travailler avec des outils d’automatisation des campagnes et de segmentation des audiences, et ils pilotent désormais la personnalisation de l’expérience digitale du client, avant même son arrivée à la réception.

Mais dans cette vague d’adoption, une variable est rarement analysée : la langue dans laquelle on s’adresse à la machine. Un revenue manager en Espagne qui, chaque matin, demande à Claude d’interpréter le rapport de demande, de proposer des ajustements tarifaires, de rédiger une réponse à un avis négatif sur Booking et de générer un résumé exécutif pour le comité de direction consomme des tokens à un rythme bien supérieur à celui de son homologue anglophone qui effectue exactement le même travail. Et cela a un coût qui, s’il devient trop élevé, peut finir par limiter l’usage de l’outil en raison d’une augmentation budgétaire inattendue.

Un scénario concret : imaginons une équipe de revenue qui effectue 50 interactions quotidiennes avec une IA. Si chaque interaction en espagnol consomme en moyenne 300 tokens de plus qu’en anglais, cela représente 15 000 tokens supplémentaires par jour. Sur un mois, 450 000 tokens additionnels. Sur une année, plus de 5 millions de tokens qui n’existeraient pas si le même travail était réalisé en anglais. Aux tarifs actuels des principaux fournisseurs, ce volume peut représenter des centaines, voire des milliers d’euros par an. Un coût qui n’apparaît dans aucun compte de résultat (P&L), mais qui existe bel et bien — et qui peut être difficile à justifier auprès d’une direction peu réceptive aux dernières technologies du marché.

 

La bonne nouvelle

L’écart se réduit, et les modèles de nouvelle génération affichent des améliorations nettes en matière d’efficacité multilingue, certains fournisseurs ayant même fait de la parité linguistique une priorité technique explicite. Par ailleurs, il existe dès aujourd’hui des stratégies concrètes pour en limiter l’impact : rédiger les prompts en anglais lorsque le livrable final peut également l’être, utiliser des modèles bilingues pour les interactions les plus récurrentes, évaluer quel fournisseur offre le meilleur ratio d’efficacité pour la langue de travail de votre équipe et — surtout — mesurer. Très peu d’équipes disposent d’une visibilité réelle sur la consommation de tokens par tâche. L’obtenir est la première étape vers l’optimisation.

En Revenue Management, nous avons l’habitude d’optimiser chaque variable : le prix, le canal, le segment, le timing. Mais nous analysons rarement le coût des outils avec le même niveau de détail que le coût d’acquisition client. Le language tax est un rappel que l’IA n’est pas neutre et que chaque décision d’implémentation — quel modèle, dans quelle langue, pour quelle tâche — a un coût associé. Connaître ce coût fait partie du métier, car en revenue, chaque euro compte, y compris ceux dépensés en tokens.