IA

Faut-il qu'un modèle calcule à chaque exécution ?

Emanuel Flury·28 août 2026·7 min de lecture
Façade en béton vue d'en bas : la même travée de fenêtres, répétée un grand nombre de fois, jusqu'à la fuite

« 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.

IAArchitectureReproductibilitéCoûts

Sources

  1. Compiled AI (2026) Compiled AI: Deterministic Code Generation for LLM-Based Workflow Automation, arXiv:2604.05150
  2. Epoch AI (2025) How much energy does ChatGPT use?, Epoch AI, Gradient Updates
  3. Google (2025) Measuring the environmental impact of delivering AI at Google Scale, arXiv:2508.15734
  4. LLM Output Drift (2026) LLM Output Drift: Cross-Provider Validation and Mitigation for Financial Workflows, arXiv:2511.07585

écrit par

Emanuel Flury
Emanuel Flury

Fondateur de Skopa. Près de dix ans d'automatisation de processus en environnements Fortune 500, aujourd'hui pour les PME suisses.

premier échange

Un processus dont nous devrions parler ?

Un premier échange est sans engagement et concret : nous examinons un déroulé réel et vous disons honnêtement si et où l'automatisation en vaut la peine.