« On va mettre de l'IA là-dessus. » La discussion s'arrête souvent là. C'est pourtant là que commence la vraie décision : non pas si un modèle intervient, mais quand.
« On va mettre de l'IA là-dessus. » Cette phrase clôt bien des discussions sur l'automatisation, alors que la vraie décision commence précisément là. Elle ne porte pas sur la présence d'un modèle, mais sur son moment : une fois à la construction, ou à chaque exécution. C'est cette question qui détermine les coûts, la reproductibilité et, en dernier lieu seulement, la consommation d'électricité.
Ce qu'une exécution coûte, elle le coûte chaque mois
Un modèle qui calcule à chaque exécution consomme des tokens à chaque exécution. Un programme construit une fois en consomme pendant sa construction, puis plus du tout. La différence n'est pas une opinion, c'est une courbe : une ligne monte à chaque passage, l'autre reste plate.
Une étude a mesuré exactement cela. Lorsqu'un déroulé est traduit une fois en code au lieu d'être envoyé à un modèle à chaque exécution, l'effort est compensé après environ 17 passages ; à 1'000 passages, la consommation de tokens est inférieure d'un facteur 57 (Compiled AI 2026). Pour une analyse mensuelle, cela représente près d'un an et demi. Pour une analyse quotidienne, un peu plus de deux semaines.
effort cumulé
L'effort selon le nombre d'exécutions
- Modèle à chaque exécution
- Modèle à chaque exécution
- Construit une fois, puis code
- Construit une fois, puis code
- Point d'équilibre
- Point d'équilibre
Schéma. Deux points sont mesurés : l'équilibre après environ 17 exécutions et le facteur 57 à 1'000 exécutions (Compiled AI 2026). La hauteur se compte en exécutions : la construction coûte ce que coûtent 17 exécutions.
Deux fois la même question, deux chiffres différents
La deuxième différence pèse plus lourd que la première dans un service financier. Un programme lancé deux fois avec les mêmes chiffres livre deux fois le même résultat. Avec un modèle de langage, cela ne va pas de soi, même réglé sur son mode le plus uniforme.
Une étude a fait traiter seize fois la même tâche à cinq modèles, à température zéro, c'est-à-dire dans le réglage censé exclure le hasard. Les petits modèles de sept à huit milliards de paramètres ont répondu de façon identique à tous les passages. Le plus grand modèle testé, de 120 milliards de paramètres, s'est répété dans 12,5 pour cent des cas (LLM Output Drift 2026). Pour un résumé, c'est supportable. Pour un chiffre qui entre dans une clôture, non.
«Un rapport que vous ne pouvez pas produire une seconde fois à l'identique n'est pas une base. C'est un instantané.»
Quiconque contrôle vos chiffres exige exactement cela : même entrée, même résultat, reproductible à tout moment. Un déroulé en code y répond de lui-même. Un modèle en exploitation doit d'abord y être contraint, et la preuve vous incombe.
La consommation d'électricité est l'argument le plus faible
On oppose souvent aux modèles de langage leur consommation d'énergie. Des trois arguments, c'est pourtant le plus faible, et il est honnête de le dire. Google a mesuré cette consommation dans sa propre production, sur toute la chaîne, de la puce au refroidissement : une requête texte médiane adressée à Gemini demande 0,24 wattheure (Google 2025). C'est peu.
Ce chiffre vaut toutefois pour une question courte. Il croît avec le volume que le modèle doit lire. Pour une requête comparable de 10'000 tokens en entrée, l'estimation s'élève à environ 2,5 wattheures, et à environ 40 pour 100'000 tokens (Epoch AI 2025). Une analyse mensuelle n'est pas une question courte. Elle pousse des tableaux entiers à travers le modèle, et elle recommence chaque mois.
Là où un modèle est le bon choix
Il n'en découle pas que les modèles n'auraient rien à faire en exploitation. Ils sont le bon choix là où la tâche est réellement neuve à chaque fois : formuler un texte, lire un document dont on ne connaît pas la structure à l'avance, répondre à une demande avec ses propres mots. Ce travail ne se traduit pas en règles fixes, parce que les règles fixes n'existent pas.
La différence tient à la répétition. Ce qui se déroule de la même façon chaque mois appartient au code. Ce qui change à chaque fois peut revenir à un modèle, et une personne le valide avant que cela ne quitte la maison. Nous nous l'appliquons à nous-mêmes : la réponse à une demande passée par notre formulaire de contact naît comme brouillon dans le modèle et ne part qu'après vérification.
Ce que vous pouvez demander au prestataire
- Un modèle calcule-t-il à chaque exécution, ou seulement à la construction ?
- Combien de fois le déroulé tourne-t-il par an, et à partir de quelle exécution le temps de construction est-il compensé ?
- Si je fais recalculer le même mois deux fois : obtient-on deux fois la même chose ?
- Que se passe-t-il si le fournisseur du modèle remplace son modèle ?
La question n'est donc pas de savoir si vous utilisez l'IA. Elle est de savoir où elle se tient : une fois à la construction, où elle produit beaucoup et ne répète rien, ou à chaque passage, où elle coûte à nouveau chaque mois et doit être justifiée à nouveau chaque mois.
Sources
- Compiled AI (2026) Compiled AI: Deterministic Code Generation for LLM-Based Workflow Automation, arXiv:2604.05150
- Epoch AI (2025) How much energy does ChatGPT use?, Epoch AI, Gradient Updates
- Google (2025) Measuring the environmental impact of delivering AI at Google Scale, arXiv:2508.15734
- LLM Output Drift (2026) LLM Output Drift: Cross-Provider Validation and Mitigation for Financial Workflows, arXiv:2511.07585

