Le blogReprendre la main · Épisode 5/5
Publié le
Passer à l'échelle : le guide de celui dont l'agent a réussi
Du premier agent qui marche à l'infrastructure qui tient, les utilisateurs, les modèles, les machines et les euros.
Série « Reprendre la main », Épisode 5/5 · 1. L'IA souveraine en France · 2. L'AI Act expliqué · 3. RGPD et IA · 4. Construire son agent IA souverain
Le problème que personne ne vous avait promis
Il y a un moment précis où les projets IA qui ont survécu entrent dans leur deuxième crise. Ce n'est pas l'échec, l'épisode 4 vous en a protégé. C'est le succès. Votre agent documentaire tourne, les collègues reviennent le lendemain, et un matin trois choses arrivent en même temps : le service voisin veut le sien, la direction veut le brancher sur un flux métier qui traite mille documents par nuit, et quelqu'un demande, innocemment, s'il pourrait lire des dossiers clients. Ou des dossiers patients.
Votre petit endpoint qui servait douze utilisateurs polis se retrouve face à une question qu'il n'a jamais eu à se poser : combien, sur quoi, et où ?
Cet épisode répond aux trois. Combien d'utilisateurs avant de changer d'infrastructure. Quel modèle pour quelle charge. Et local ou API, avec les chiffres à chaque fois, parce que c'est la question qu'on vous posera en comité budget.
L'idée-force : ce ne sont pas les humains qui font basculer le calcul
Voici l'intuition fausse que cet épisode veut démonter : « plus on a d'utilisateurs, plus le self-hosting devient rentable ». C'est vrai à la marge, et faux en pratique, parce que les humains consomment très peu.
Faites le compte. Une API souveraine facture le modèle au tarif d'un Mistral Medium, de l'ordre de 1,50 €/M tokens en entrée, 7 €/M en sortie. À l'échelle d'un assistant humain, où chacun pose quelques dizaines de requêtes par jour, la facture se compte en quelques euros par personne et par mois. Le prix d'un café. Aucun serveur GPU au monde ne s'amortit contre une addition pareille.
Ce qui fait réellement basculer le calcul, ce sont deux choses, et aucune des deux n'est un humain :
-
Les machines. Un pipeline qui synthétise chaque nuit dix mille documents, un agent qui boucle en autonomie, un flux de production continu. Là, on ne compte plus en utilisateurs mais en centaines de millions de tokens. C'est ce régime-là : celui des très gros volumes machine, continus, qui finit par rendre l'inférence locale plus rentable que l'API. Pas la foule des humains : la meute des automates.
-
Le droit. Dès que des données de santé identifiantes, du secret défense ou du secret professionnel entrent dans le corpus, la question du coût devient secondaire : c'est l'hébergement qui est prescrit (on y revient plus bas, et c'est le passage le plus important de cet épisode pour certains d'entre vous).
Gravez la règle : on ne dimensionne pas une infrastructure IA sur le nombre d'utilisateurs inscrits, mais sur le volume de tokens et la nature des données. Le reste en découle.
Première question : combien d'utilisateurs simultanés ?
Deuxième intuition fausse à démonter : confondre utilisateurs totaux et utilisateurs concurrents. Deux cents collaborateurs qui posent chacun quelques questions par jour, cela fait rarement plus de cinq à dix requêtes au même instant. C'est ce chiffre-là, la concurrence, qui dimensionne les machines.
Et c'est ici qu'une distinction technique de l'épisode 4 prend toute son importance. Ollama, votre bac à sable, ne traite qu'un nombre limité de requêtes en parallèle par défaut, puis met les suivantes en file d'attente : au-delà d'une poignée d'utilisateurs simultanés, l'attente s'allonge et l'expérience meurt. vLLM (ou ses cousins SGLang, TensorRT-LLM) fait autre chose : du batching continu, il sert bien plus de conversations en parallèle sur le même GPU, en entrelaçant les calculs. C'est la différence entre une machine à café et un percolateur de brasserie. Même eau, même café, pas le même service.
La grille pratique :
| Utilisateurs simultanés | Ce qu'il faut | Ordre de grandeur |
|---|---|---|
| 1 à 5 | Ollama suffit (proto, démo, équipe pilote) | Le laptop, ou un mini PC |
| 5 à 50 | vLLM sur un GPU sérieux | Un modèle ~24B, quantifié ou non |
| 50 à 200+ | vLLM sur plusieurs GPU, ou un modèle plus gros bien servi | L'infrastructure devient un métier |
Un détail qui n'en est pas un : la mémoire GPU ne sert pas qu'à loger le modèle. Chaque conversation ouverte y maintient son cache de contexte (le KV cache), qui grossit avec la longueur des échanges. Un RAG documentaire aux contextes copieux multiplié par trente sessions simultanées, ce sont des dizaines de gigaoctets en plus des poids. Dimensionnez avec de la marge, ou vos utilisateurs découvriront le message « out of memory » à l'heure de pointe.
Deuxième question : quel modèle pour quelle charge ?
L'épisode 4 vous a donné la grille du premier agent. À l'échelle, elle s'affine, et un concept nouveau entre en scène : la différence entre modèle dense et modèle MoE (Mixture of Experts).
Un modèle dense active tous ses paramètres à chaque mot généré. Un MoE n'en réveille qu'une fraction, des « experts » sélectionnés à la volée. Conséquence directe : à taille affichée égale, le MoE est beaucoup plus rapide, parce qu'en inférence, le goulot d'étranglement n'est presque jamais le calcul mais la bande passante mémoire, la vitesse à laquelle on fait circuler les poids. C'est pour cela qu'un MoE de 235 milliards de paramètres peut tourner plus vite qu'un dense de 128 milliards : il ne déplace qu'une vingtaine de milliards de paramètres par token.
La grille 2026, côté Mistral (mais la logique vaut ailleurs) :
- Mistral Small 4 (119B, MoE, 6,5B actifs, Apache 2.0) : toujours le cheval de trait. Grâce au MoE (6,5B actifs par token), un seul GPU haut de gamme le sert avec vLLM à de nombreux utilisateurs simultanés. Pour 80 % des agents internes, chercher plus gros est un caprice.
- Mistral Medium 3.5 (128B, dense, poids ouverts) : le frontier auto-hébergeable, taillé pour l'agentique lourde : raisonnement long, appels d'outils en rafale, code. Mais 128 milliards de paramètres denses, c'est un déménagement complet de la mémoire à chaque token : comptez quatre GPU de classe datacenter pour le servir dignement en multi-utilisateurs, ou deux très gros GPU en version quantifiée.
- Mistral Large (MoE, centaines de milliards) : datacenter ou API. À l'échelle d'une PME ou d'une ETI, on ne l'auto-héberge pas, on le loue.
Le réflexe d'architecte : ne montez en modèle que si l'évaluation le réclame. Votre jeu de test de l'épisode précédent est là pour ça. Si Small répond juste, Small en production, et le budget GPU divisé par quatre.
L'aparté hardware : la sirène des mini PC « à mémoire unifiée »
Vous les avez vus passer : ces boîtiers compacts, façon Mac mini, vantant 128 Go de « mémoire unifiée » pour faire tourner des gros modèles à la maison, les machines à base de puce AMD Strix Halo, autour de 1 500 à 2 500 €, ou leurs équivalents. Disons-le clairement, parce que la question revient dans tous les projets : ce sont d'excellentes machines mono-utilisateur, et de mauvais serveurs.
Leur mémoire est vaste mais lente (~256 Go/s, contre 2 000 à 3 350 Go/s pour un GPU datacenter comme le H100). Un gros modèle dense y génère ses tokens au compte-gouttes, et surtout ces machines ne pratiquent pas le batching qui fait le multi-utilisateurs. Leur place est réelle, le poste de travail du développeur, le labo, le POC souverain sur un coin de bureau, mais elle s'arrête à la porte de la production partagée. Si quelqu'un vous propose de servir cinquante collaborateurs sur un mini PC, c'est la démo confondue avec la prod, piège n° 2 de l'épisode 4, dans un joli boîtier.
Troisième question : local ou API : les chiffres, à chaque fois
Trois voies, trois profils de coût. Les montants sont des ordres de grandeur mi-2026, à revérifier avant engagement, le marché de la mémoire est en pénurie et les prix bougent.
Voie 1, L'API souveraine. Zéro capex, zéro ops, contrat de non-rétention des données (Zero Data Retention, ZDR) à exiger. Coût : proportionnel à l'usage. Pour de l'assistant humain, quelques centaines d'euros par mois même à cent utilisateurs. C'est la bonne réponse par défaut, et elle le reste bien plus longtemps qu'on ne le croit.
Voie 2, Le GPU loué en France. Un GPU professionnel de milieu de gamme (type L40S, 48 Go de VRAM) se loue autour de 1,50 €/h, un H100 (80 Go de VRAM) autour de 2 à 3 €/h chez les acteurs souverains. En 24/7, comptez ~1 500 à 2 000 €/mois pour servir un Small confortablement sur un H100, de l'ordre de 9 000 à 11 000 €/mois pour un Medium en pleine précision sur quatre H100 interconnectés en NVLink. Réversible, sans capex, hébergeable sur infrastructure certifiée. C'est la voie des volumes machine et des données sensibles.
Voie 3, L'achat. Un serveur à quatre GPU représente un investissement matériel lourd, à immobiliser d'un coup. Amorti sur trois ans, la voie 3 bat la voie 2 à condition de tourner en continu, et d'ajouter le poste que tout le monde oublie : l'exploitation. Monitoring, mises à jour, sécurité, astreinte : opérer du GPU en production, c'est un métier, avec des compétences ops dédiées et du temps humain récurrent. Un serveur GPU est un produit, pas un projet, l'agent orphelin de l'épisode 4 a un cousin, le serveur orphelin, et il coûte plus cher.
Le tableau de bascule, en une ligne : API tant que l'usage reste modéré ; location souveraine quand les volumes machine explosent, ou dès que la donnée l'exige ; achat quand la charge est continue, prévisible, et l'équipe d'exploitation réelle.
Le cas qui inverse tout : la donnée de santé (et ses cousines)
Maintenant, le passage que certains lecteurs attendaient, ceux dont l'agent doit lire des comptes rendus médicaux, des dossiers patients, des données couvertes par le secret. Ici, la logique économique des trois voies passe au second plan : c'est le droit qui choisit l'architecture.
En France, l'hébergement de données de santé identifiantes exige un hébergeur certifié HDS, et cette exigence court sur toute la chaîne : le modèle, la base vectorielle, l'orchestration. Souvenez-vous de l'idée-force de l'épisode 4 : l'agent est aussi souverain que sa brique la moins souveraine. Version santé : l'agent est aussi conforme que sa brique la moins certifiée. Or les API mutualisées des fournisseurs de modèles, y compris françaises, ne sont, à ce jour, généralement pas qualifiées HDS. Vérifiez à la date de votre projet, mais ne le présumez jamais.
Les architectures qui tiennent la route en 2026 :
- Le self-hosting sur infrastructure HDS (OVHcloud, Scaleway, Outscale, ou votre propre infra certifiée) : modèle open weight servi par vLLM, base vectorielle et orchestration au même endroit. La voie royale, celle qui aligne les cinq briques de l'épisode 4 au même endroit.
- Le montage hybride avec pseudonymisation en amont : un filtre supprime ou remplace les identifiants avant que le texte ne parte vers un modèle plus puissant, la réponse est ré-identifiée côté client. Puissant, mais le filtre devient votre pièce critique : et votre responsabilité.
- L'API sous contrat renforcé + hébergeur HDS, un schéma que des acteurs français de l'IA médicale ont validé publiquement : modèle français sous Zero Data Retention, données hébergées chez un certifié HDS. Faisable, mais c'est un montage contractuel précis, pas une case cochée dans un formulaire.
Et n'oubliez pas les épisodes 2 et 3 : l'IA en santé est classée à haut risque par l'AI Act, l'AIPD est obligatoire avant la mise en œuvre, POC compris, et les sanctions se cumulent (RGPD d'un côté, Code de la santé publique de l'autre). Un dernier mot de prudence, le même qu'à chaque épisode : ceci est une carte, pas un avis juridique. La qualification de votre traitement appartient à votre DPO et à votre conseil.
Le budget, sans langue de bois
Quatre scénarios types, pour fixer les idées :
- 100 collaborateurs, assistant documentaire interne, données non sensibles → API souveraine + ZDR : 200 à 500 €/mois. N'achetez rien.
- Le même, plus un pipeline nocturne de traitement documentaire massif → un GPU professionnel loué en France, Small servi par vLLM : ~1 500 €/mois, ou l'achat du matériel si la charge est pérenne.
- Agent frontier pour de l'agentique lourde (code, raisonnement long), données non sensibles → Medium via API pour commencer ; passage en location 4 GPU (~9 000-11 000 €/mois) seulement si le volume le prouve.
- Données de santé identifiantes, quel que soit le volume → self-hosting sur infrastructure HDS : 2 000 à 8 000 €/mois selon le modèle, plus l'AIPD, plus l'exploitation. Ce n'est pas le scénario le moins cher. C'est le seul qui soit légal.
Et toujours le poste invisible : l'évaluation continue, la mise à jour du corpus, la supervision. À l'échelle, il ne rétrécit pas, il devient le cœur du métier.
Les quatre pièges du passage à l'échelle
1. Dimensionner sur les inscrits, pas sur les simultanés. Vous achèterez quatre fois trop de GPU, ou vous saturerez à la première heure de pointe. Mesurez la concurrence réelle pendant un mois avant tout engagement.
2. Oublier que le contexte mange la mémoire. Le modèle tient sur le GPU, la démo passe, et la production tombe : trente sessions RAG à long contexte ont dévoré le KV cache. Prévoyez la marge, testez en charge.
3. Acheter le gros serveur avant d'avoir mesuré. Le matériel évolue vite, bande passante mémoire en forte hausse annoncée sur les prochaines générations, prix de la mémoire volatils, modèles qui rapetissent à qualité égale. La location est votre amie tant que la charge n'est pas prouvée sur six mois.
4. La brique non certifiée cachée, version réglementée. Le cousin santé du piège n° 3 de l'épisode 4 : tout est HDS sauf la base vectorielle, ou sauf le service d'embeddings, ou sauf les logs. Auditez la chaîne complète avec la même rigueur que l'itinéraire de vos octets. En secteur réglementé, une brique oubliée n'est pas une dette technique : c'est une infraction.
L'encadré à découper : trois mesures, trois décisions
| 📏 La mesure | ⚖️ Le seuil de bascule | ✅ La décision qu'elle dicte |
|---|---|---|
| Le volume de tokens, machines comprises, pas seulement les humains | Les gros volumes machine (pipelines, agents autonomes), pas la foule humaine | Quand quitter l'API. Tant que ce sont des humains : API souveraine + ZDR, n'achetez rien. Quand les machines saturent le débit : GPU loué, puis acquis si la charge est continue. |
| Les utilisateurs simultanés, pas les inscrits | ~ 5 (sortie du bac à sable) · ~ 50 (sortie du GPU unique) | Combien de machines, quel moteur. Ollama → vLLM sur un GPU → multi-GPU. Et de la marge pour le cache de contexte. |
| La sensibilité juridique des données, pas le volume | Donnée de santé identifiante, secret professionnel | Où héberger. Chaîne complète sur infrastructure certifiée HDS, AIPD avant mise en œuvre. Ici, le droit choisit, pas le coût. |
Le mot de la fin
L'épisode 4 se terminait sur une promesse : bien construire, c'est déjà être en règle. L'échelle y ajoute son corollaire : bien mesurer, c'est déjà bien dépenser. Le volume de tokens vous dit quand quitter l'API. La concurrence réelle vous dit combien de GPU. La nature des données vous dit où. Trois mesures, trois décisions, et aucune ne se prend au doigt mouillé en comité de direction.
Remarquez, une dernière fois, ce qui s'est passé en chemin : la frugalité, la conformité et la performance se sont encore révélées être le même geste. Le modèle le plus petit qui passe l'évaluation est à la fois le moins cher, le plus rapide et le plus simple à héberger souverainement. À l'échelle comme au premier agent : la sobriété n'est pas une contrainte, c'est l'architecture.
Alors, cette montée en charge : mesurer d'abord, l'API tant qu'elle suffit, un GPU loué quand les machines s'en mêlent, l'infrastructure certifiée quand la donnée l'exige. Vous avez la carte, la même que d'habitude, à une échelle de plus.
Il ne reste qu'à monter.
📖 Dans la même série, Épisode 1 : l'IA souveraine en France · Épisode 2 : l'AI Act expliqué · Épisode 3 : RGPD et IA · Épisode 4 : construire son premier agent.
Sources principales : documentation Mistral AI (poids ouverts Small/Medium), grilles tarifaires des API et GPU souverains (Scaleway, OVHcloud), benchmarks d'inférence vLLM 2026, retours de terrain sur les plateformes à mémoire unifiée (AMD Strix Halo, mini PC 128 Go), référentiel HDS (ANS), recommandations CNIL, règlement UE 2024/1689. Les prix sont des ordres de grandeur mi-2026, en période de tension sur le marché de la mémoire : vérifiez les grilles à jour avant tout engagement.