Coût et impact environnemental de l'IA

Le coût d'un usage de l'IA générative se calcule en tokens : chaque fournisseur facture un prix par million de tokens en entrée et un autre, plus élevé, en sortie. Son impact environnemental vient de l'électricité, de l'eau et du matériel des centres de données, pour l'entraînement des modèles comme pour chaque requête. Ce chapitre t'apprend à chiffrer les deux, avec des sources, et à choisir les pratiques qui réduisent la facture et l'empreinte.

Le prix au token

Les prix se donnent en dollars, hors taxes, par million de tokens (souvent noté MTok). Voici ceux d'Anthropic en novembre 2026 :

Trois remarques valent pour tous les fournisseurs :

• la sortie coûte plus cher que l'entrée, ici cinq fois plus : générer demande un passage dans le modèle par token, alors que l'entrée est lue d'un bloc ;
• les tokens de réflexion d'un modèle qui raisonne sont des tokens de sortie, donc facturés comme tels ;
• des remises existent : le traitement par lots (batch), pour les tâches qui peuvent attendre quelques heures, coûte 50 % de moins chez Anthropic, et une partie d'un prompt répétée d'une requête à l'autre peut être mise en cache et refacturée à une fraction du prix d'entrée.

Les prix changent souvent, généralement à la baisse pour une qualité donnée : vérifie la page de tarifs du fournisseur avant tout calcul de budget.

Calculer un budget

La formule tient en une ligne :

coût = nombre de requêtes × (tokens d'entrée × prix d'entrée + tokens de sortie × prix de sortie) / 1 000 000

L'assistant de tri de Sorbier traite 200 demandes par jour ouvré, soit 4 400 par mois de 22 jours. Chaque requête envoie 1 500 tokens (consignes, exemples, courriel) et en reçoit 300.

Pour un tri simple, le plus petit modèle peut suffire et coûter quarante fois moins : seul un test sur une centaine de vrais courriels le dira. Ce qui fait grimper la facture, en pratique :

• l'historique renvoyé à chaque tour d'une conversation (chapitre 7) ;
• les passages du RAG ajoutés à chaque question ;
• la réflexion d'un modèle qui raisonne, réglée trop haut pour une tâche simple ;
• les boucles d'un agent, qui relit tout son contexte à chaque appel d'outil ;
• les nouvelles tentatives après une erreur.

Réduire la facture

1. Choisir le plus petit modèle qui suffit, mesuré sur de vrais exemples, pas sur une impression.
2. Raccourcir : un prompt système concis, un historique résumé, seulement les passages utiles.
3. Plafonner : max_tokens adapté, nombre de requêtes par utilisateur, limite de dépense chez le fournisseur.
4. Baisser l'effort de réflexion pour les tâches simples.
5. Mettre en cache la partie fixe des prompts, et regrouper par lots ce qui n'est pas urgent.
6. Ne pas appeler le modèle quand une règle suffit : une expression régulière trouve un numéro de ticket, pas besoin d'un LLM.

Modèle hébergé ou modèle local ?

Pour quelques dizaines de requêtes simples par jour sur des données sensibles, un petit modèle local est souvent le bon choix. Pour du code ou des raisonnements complexes, un modèle hébergé reste devant. Rien n'empêche de combiner les deux : le modèle local pour les données internes, l'API pour le reste.

Mesurer un modèle local

Un modèle local ne t'envoie pas de facture, mais il occupe un serveur : mesure-le avant de promettre un temps de réponse. Chaque réponse d'Ollama contient ses propres compteurs :

Les durées sont en nanosecondes. La vitesse de génération, en tokens par seconde, vaut donc eval_count / (eval_duration / 1 000 000 000). Sur un serveur sans carte graphique, compte quelques tokens à quelques dizaines de tokens par seconde selon la taille du modèle : une réponse de 300 tokens peut demander une demi-minute.

Deux commandes complètent le tableau :

ollama ps        # modèles chargés, mémoire occupée, et répartition entre CPU et GPU
free -h          # mémoire vive restante sur le serveur

Sur srv-ia, ajoute l'hôte à la supervision du labo : charge du processeur, mémoire, temps de réponse de l'API. Le cours Supervision montre comment superviser un serveur Linux avec l'agent Zabbix et tracer ses courbes dans Grafana.

L'impact environnemental

L'empreinte d'un modèle a trois sources :

• la fabrication du matériel : cartes graphiques et serveurs demandent des métaux et de l'eau, et ont une durée de vie de quelques années ;
• l'entraînement : des semaines de calcul sur des milliers de cartes graphiques, une fois par modèle ;
• l'inférence : chaque requête consomme un peu d'électricité, et de l'eau pour refroidir les centres de données, multipliée par des milliards de requêtes.

Les chiffres disponibles, avec leur périmètre :

Ces chiffres ne se comparent pas directement : périmètres différents (fonctionnement seul pour Google, cycle de vie complet pour Mistral), modèles différents, électricité plus ou moins carbonée selon le pays. Ils viennent aussi des entreprises elles-mêmes, sans vérification indépendante complète. Ce qu'on peut en retenir : une requête isolée pèse peu, mais l'usage se compte en milliards de requêtes, les modèles les plus gros et les tâches les plus longues consomment davantage, et la demande des centres de données augmente vite.

Les pratiques sobres

En France, l'AFNOR a publié en juin 2024 un référentiel gratuit, l'AFNOR Spec 2314 « Référentiel général pour l'IA frugale », avec une méthode de mesure et 31 fiches de bonnes pratiques. Son idée centrale : avant d'optimiser un modèle, se demander si l'IA est nécessaire. Pour un service informatique, ça donne :

• ne pas utiliser l'IA par réflexe quand un script, une recherche ou une règle font le travail ;
• choisir le plus petit modèle suffisant, et un modèle local quand c'est possible ;
• limiter les sorties : réponses courtes, pas de génération d'images ou de vidéos sans besoin ;
• réutiliser : garder un résultat plutôt que régénérer la même chose, mettre en cache ;
• mesurer : nombre de requêtes, tokens, consommation du serveur, pour décider sur des faits.

Ces pratiques rejoignent celles de l'écoconception des services numériques : la sobriété fait aussi baisser la facture.

Exercices