Domination du « à la demande »
Depuis quelques années, l’intégration des modèles de langage (LLM) dans les processus administratifs s’est faite, pour une large part, par le biais d’API externes. Le modèle est appelé à la demande, et la collectivité ou l’entreprise paie en fonction du volume de tokens traités.
Cette approche présente des avantages indéniables en phase de test ou de faible volume : aucune acquisition de matériel, aucun effort d’exploitation. Mais elle repose sur un modèle économique qui, à l’usage, peut devenir lourd : un coût récurrent, indéfini et non maîtrisé, qui suit la croissance de l’utilisation sans jamais redescendre.
Dès qu’une fonction est intégrée au quotidien : aide à la rédaction d’actes, réponse automatisée aux usagers, traitement de dossiers, assistant interne, la facture d’API peut atteindre, sur une année, des sommes significatives. Et elle continue de croître à chaque nouvelle utilisation.
Cet article fait le pari que l’utilisation de l’IA générative va croître les années prochaines dans les collectivités. Cela pose des problèmes de maîtrise technique, de maîtrise des données, de maîtrise budgétaire et de maîtrise de son impact environnemental.
Pour adresser un certain nombre de ces enjeux majeurs, il existe une alternative qui gagne chaque année en pertinence : acquérir sa propre puissance d’inférence, à commencer par un serveur équipé d’un GPU professionnel.
Se doter d’un serveur GPU pour l’inférence IA n’est pas une course à la puissance ni un réflexe technologique. C’est, dans un certain nombre de cas, une décision économique et stratégique pertinente : rentabilité atteinte aux environs de deux ans, maîtrise des coûts sur le long terme, autonomie et souveraineté des données, résilience du service.
Pour la Ville d’Échirolles, qui intègre progressivement l’IA dans ses services, la question n’est donc pas de savoir s’il faut se doter d’une telle capacité, mais à quel périmètre, à quel volume, et à quelles conditions techniques elle devient plus rentable que l’achat continu de tokens. Un sujet qui mérite d’être étudié de près.
Le principe : coût fixe vs coût récurrent
La logique est la suivante. L’API facture chaque requête, tant que l’on s’en sert. C’est un coût variable, infini. Le serveur GPU, lui, implique un investissement initial, puis un coût d’exploitation annuel maîtrisé (électricité, maintenance). La puissance reste disponible aussi longtemps que l’appareil fonctionne.
La question n’est donc pas « lequel coûte le moins », mais « à quel volume d’utilisation le coût fixe devient inférieur au coût récurrent ».
Étude de cas basé sur le GPU NVIDIA RTX 6000 Pro Blackwell (Server Edition)
Pour un usage institutionnel sérieux, le choix se porte rarement sur du matériel grand public. Le NVIDIA RTX 6000 Pro Blackwell Server Edition : GPU professionnel de la dernière génération Blackwell, doté d’une large mémoire VRAM (environ 96 Go) et d’une consommation d’énergie de l’ordre de 300 W, constitue un point de départ pertinent pour héberger des modèles de taille moyenne à grande, avec des débits élevés.
Attention : les caractéristiques précises (capacité mémoire, débit, prix) de ce modèle évoluent rapidement. Les chiffres avancés dans cet article sont à confirmer avant toute décision d’acquisition, auprès des fournisseurs ou des fiches techniques officielles NVIDIA.
L’investissement initial
La station serveur complète, GPU inclus, représente un investissement de départ de l’ordre de 35 000 € : GPU RTX 6000 Pro Blackwell (environ 15 000 €) et infrastructure serveur associée (environ 20 000 €).
Le coût annuel d’exploitation
Avec une consommation d’environ 450 W pour le serveur complet en charge (GPU 300 W + station d’accompagnement) :
- Électricité : environ 3 940 kWh par an, à environ 0,194 €/kWh (tarif réglementé EDF, option Base, 3 à 6 kVA), soit environ 765 €/an.
- Maintenance et renouvellement : environ 200 €/an.
- Total annuel environ 1 000 €/an.
Le gain par rapport à l’API
Sur ce type de GPU, un modèle de 70 à 70 milliards de paramètres tourne à des débits de l’ordre de 50 tokens par seconde, et un modèle de 30 à 35 milliards de paramètres (largement suffisant dans notre cas, où la génération d’images ou de vidéos n’est pas nécessaire) bien au-delà. À titre indicatif, une structure qui consomme plusieurs millions de tokens par mois paierait entre 15 000 et 30 000 €/an via une API, selon le mix de modèles utilisés.
Résultat : le seuil de rentabilité se situe aux environs de deux ans, puis le coût d’inférence annuel devient une fraction de la facture API équivalente.
Le calcul sur cinq ans
Le tableau ci-dessous compare, sur une période de cinq ans, le coût cumulé du serveur équipé du RTX 6000 Pro Blackwell (scénario d’acquisition, investissement initial de 35 000 €) et du coût d’une API interne au même volume de traitement (estimé à 18 000 €/an, fourchette moyenne). Les chiffres sont indicatifs et à affiner selon le volume réel et les tarifs en vigueur.
| Année | Coût cumulé serveur GPU | Coût cumulé API (18 000 €/an) |
|---|---|---|
| Année 1 | 36 000 € | 18 000 € |
| Année 2 | 37 000 € | 36 000 € |
| Année 3 | 38 000 € | 54 000 € |
| Année 4 | 39 000 € | 72 000 € |
| Année 5 | 40 000 € | 90 000 € |
| Économie sur 5 ans | environ 50 000 € |
Seuil de rentabilité : selon ce scénario, l’investissement est rentabilisé aux environs de deux ans (le coût de l’API dépasse celui du serveur à partir de la troisième année). Au-delà, chaque année supplémentaire d’exploitation du serveur coûte environ 1 000 € contre environ 18 000 € pour l’API. Ce seuil se déplace selon le volume réel de tokens traités : plus il est élevé, plus la rentabilité du serveur est rapide.
Les motifs qui rendent l’investissement pertinent
1. Maîtrise des coûts sur le long terme
Un matériel acheté est un coût maîtrisé sur plusieurs années, à l’opposé d’un forfait API susceptible de croître et de changer de conditions. Cette stabilité facilite la budgétisation pluriannuelle.
2. Résidence et souveraineté des données
Lorsqu’un traitement porte sur des données sensibles : dossiers d’usagers, informations à caractère personnel, documents administratifs, ne jamais sortir les données d’un réseau maîtrisé est une nécessité. L’auto-hébergement garantit la souveraineté des données et accompagne le respect du RGPD.
3. Résilience et autonomie
Un service IA hébergé en interne ne dépend ni des quotas d’un fournisseur, ni de ses pannes, ni de ses évolutions tarifaires. Pour une fonction support essentielle, cette indépendance a une valeur que la seule facture ne mesure pas.
4. Maîtrise de l’impact environnemental
Disposer de sa propre infrastructure permet de mesurer précisément la consommation électrique générée. Des solutions de compensation de cette surconsommation peuvent être travaillées pour limiter l’empreinte environnementale de la solution déployée. Un enjeu crucial dans un contexte d’augmentation sensible des émissions de CO2 liée à l’IA et aux datacentres géants.
5. Montée en charge maîtrisée
Un GPU professionnel comme le RTX 6000 Pro permet d’héberger des modèles de grande taille localement, sans dépendre de la disponibilité ni des limites de débit d’un service externe.
Les limites de l’auto-hébergement
Il est nécessaire de rester lucide : l’acquisition d’un serveur GPU n’est pas une solution universelle.
- Un effort technique réel. Auto-héberger un modèle, ce n’est pas brancher une carte. Il faut installer, configurer, optimiser, mettre à jour, surveiller, sauvegarder. Cet effort d’exploitation (DevOps / ML Ops) représente un coût caché, souvent sous-estimé, qui peut annuler l’avantage économique si l’équipe n’y est pas préparée.
- Un volume faible ou irrégulier. Si l’IA n’est utilisée que ponctuellement, le coût fixe du matériel et du temps consacré à son exploitation dépasse largement le coût de l’API.
- Des modèles très gros. Certains modèles de pointe ne tiennent pas sur un GPU de taille humaine. Pour ces usages, l’API reste la seule option réaliste.
- Une exigence de performance maximale. Les fournisseurs d’API proposent souvent des débits plus élevés et des modèles plus récents que du matériel, qui date rapidement.
Trancher selon le périmètre d’usage
| Situation | Choix recommandé |
|---|---|
| Volume faible, usage ponctuel | API |
| Volume élevé, usage régulier | Serveur GPU |
| Données sensibles, nécessité de souveraineté | Serveur GPU (auto-hébergement) |
| Besoin de modèles de pointe, équipe réduite | API |
| Fonction support critique, besoin de résilience | Serveur GPU |
La règle générale : plus l’utilisation est forte et régulière, plus l’investissement devient rentable. Plus elle est faible, plus l’API reste attractive.
