Le coût caché du cloud

Chapitre 5 — Le coût caché du cloud

Le récit dominant de ces cinq dernières années est que le cloud est économique, évolutif et simple. Pour de nombreuses charges de travail, c'est parfaitement vrai. Pour les RAG d'entreprise, de plus en plus souvent, ce n'est pas le cas. Et le moment où vous vous en rendez compte est généralement à la fin du premier trimestre, lorsque la facture arrive.

Prenons la ligne de coût la plus sous-estimée du compte : les API des modèles de vision. Lorsqu'une entreprise ingère son archive photographique dans un RAG moderne, chaque photo doit être "décrite" par un modèle multimodal qui en extrait le contenu, les objets, le contexte, les éventuels textes superposés, l'humeur, la composition. Un grand fournisseur européen de modèles — encore sans nom — proposait, en 2025, un excellent modèle de la famille Qwen de 32 milliards de paramètres, à un prix par image intéressant. Le problème, découvert seulement sur le terrain et après des mois de production : sous charge, le fournisseur tronquait les réponses. Pas toujours, pas de manière prévisible, pas lorsque l'équipe de test était présente : aléatoirement. Une photo sur dix, parfois une sur cinq, revenait avec un JSON coupé à moitié, mal parsé, avec des métadonnées partielles ou nulles. Les temps montaient en flèche, passant de dix secondes à deux cents secondes par image, sans schéma. La facture des retries — car les retries se paient, chaque appel, même celui que le serveur tronque — était plus élevée que prévu. La base de données était hétérogène : certaines photos riches en métadonnées, d'autres tronquées. Et l'équipe n'arrivait pas à reproduire le problème dans les environnements de test, car en test la charge était faible et tout fonctionnait.

La solution est arrivée en trois parties : un prompt plus compact (les réponses plus courtes sont moins susceptibles d'être tronquées), une logique de nouvelle tentative intelligente (si la réponse prend plus de cinquante secondes et revient vide, réessayez immédiatement) et — lorsque le volume le justifie — la possibilité de sauter complètement le cloud et d'exécuter le modèle de vision sur un GPU local, plus lent mais déterministe. L'architecture adéquate, d'après cette expérience, n'est ni "cloud toujours" ni "local toujours". Elle est "choisir pour chaque appel, en fonction de ce qui est nécessaire à ce moment-là".

Il y a ensuite le chapitre des requêtes. Chaque recherche utilisateur, dans un RAG cloud-natif classique, déclenche une cascade d'appels d'API payants. Un pour l'intégration de la question. Un pour la classification intentionnelle (quel type de question est-ce ?). Un pour le réévaluation des documents. Un pour la génération de la réponse finale. Chacun coûte une fraction de centime. Pour un service interne avec cinquante utilisateurs et dix mille requêtes par jour — ce qui n'est pas peu, mais pas non plus un nombre énorme pour une entreprise moyenne — le montant mensuel atteint des chiffres qui feraient froncer les sourcils même à un directeur financier indulgent. Et la croissance est linéaire : vous doublez le nombre d'utilisateurs, vous doublez le montant. Il n'y a pas d'économies d'échelle dans les tokens consommés, pas pour vous.

Il y a aussi un problème qui était latent en 2025 et qui est devenu central en 2026 : chaque requête unique envoie des fragments de documents d'entreprise – parfois confidentiels, parfois couverts par des accords de confidentialité, parfois soumis à des réglementations sectorielles – aux serveurs d'un fournisseur externe, dans des juridictions qui ne coïncident pas toujours avec la vôtre, avec des politiques de conservation des journaux qui ne sont pas toujours transparentes. Plus d'une entreprise européenne, au cours des dix-huit derniers mois, a découvert – généralement lors d'un audit, souvent déclenché par un client inquiet ou une vérification ISO – que ses contrats, listes de prix et spécifications techniques avaient été traités (et potentiellement enregistrés à des fins d'"amélioration du service") par des infrastructures hors UE. La surprise a généralement coûté plus cher que les économies réalisées en évitant l'achat de matériel local.

L'alternative n'est pas le dogme opposé. "Non au cloud, oui au local" est aussi faux que "oui au cloud toujours". L'alternative est une architecture qui vous permette de choisir, pour chaque élément de la chaîne de traitement — intégration, classification, rerang, vision, génération finale — si vous voulez utiliser un modèle cloud ou un modèle local, et de changer d'avis en une journée, pas en un trimestre. Cela nécessite une conception où les fournisseurs sont interchangeables, où aucune pièce n'est figée au nom d'une entreprise spécifique, où le passage de Regolo à Ollama (ou vice versa) est une ligne de configuration, et non une réécriture. Et cela, jusqu'à récemment, était rare. Les frameworks populaires, malgré la façade de "indépendance vis-à-vis du fournisseur", étaient en réalité très liés à quelqu'un.