Le modèle sélectionné est saturé. Veuillez essayer un autre modèle.
« Le modèle sélectionné est saturé. Veuillez essayer un autre modèle. »
Je trouve ce message de plus en plus difficile à accepter.
Il apparaît précisément lorsque j’ai décidé qu’une tâche mérite un niveau d’intelligence particulier. J’ai choisi le modèle, fourni le contexte et préparé le travail. Puis le service me demande de faire un autre choix parce que la capacité nécessaire pour fournir cette intelligence n’est pas disponible.
Pour une expérience occasionnelle, c’est un désagrément. Lorsque l’IA devient partie intégrante de la manière dont une équipe développe des logiciels, prend des décisions ou sert ses clients, cela devient un problème métier.
À quel point l’IA doit-elle devenir fiable avant que les entreprises puissent s’y fier ?
Les décimales comptent
Les deux captures d’écran de pages d’état ci-dessous ont retenu mon attention. La capture d’écran de ChatGPT indique 99,52 % de disponibilité. La capture d’écran de claude.ai indique 99,53 % sur les 90 derniers jours.
Une précision importante s’impose. Ces captures d’écran concernent ChatGPT et claude.ai. Les contrats API d’entreprise ont leur propre périmètre et leurs propres engagements. La page d’état d’OpenAI explique également que ses métriques de disponibilité agrègent les niveaux de service, les modèles et les types d’erreurs, et que l’expérience de chaque client peut varier. Une journée colorée peut représenter un incident partiel ou des performances dégradées ; cela ne signifie pas que tout le monde était incapable de travailler pendant 24 heures. La page d’état de Claude suit séparément son application web, son API et son service de codage.
Même avec ces précisions, les pourcentages méritent attention. Pour les flux de travail d’IA critiques pour l’entreprise, je commencerais par un objectif de disponibilité de 99,95 %. Certaines applications nécessiteront davantage. D’autres peuvent tolérer des retards. L’exigence doit découler des conséquences d’une défaillance.
99,50 % et 99,95 % peuvent sembler presque identiques dans une présentation. Exprimez-les en temps, et la différence devient bien plus difficile à écarter.
| Disponibilité | Indisponibilité par mois | Indisponibilité par an |
|---|---|---|
| 99,50 % | 3 heures 36 minutes | 43 heures 48 minutes |
| 99,95 % | 21 minutes 36 secondes | Environ 4 heures 23 minutes |
La différence n’est que de 0,45 point de pourcentage. Elle représente dix fois plus de temps d’indisponibilité au niveau de disponibilité inférieur.
Et l’impact métier dépend du moment où ces minutes surviennent. Une interruption lors d’un traitement en arrière-plan nocturne diffère d’une interruption lors d’une escalade client ou d’une livraison logicielle. Le pourcentage est un point de départ. Le travail interrompu est ce que l’entreprise subit réellement.
« Essayez un autre modèle » change le travail
Il y a quelque chose de particulièrement inconfortable dans le remède proposé.
Si j’ai sélectionné un modèle parce que je lui fais confiance pour une tâche de programmation difficile, me demander d’utiliser une alternative moins capable m’oblige à reconsidérer la qualité du travail que je suis prêt à accepter.
Bien sûr, un autre modèle n’est pas automatiquement moins bon. Un modèle plus petit peut être excellent pour une tâche bien définie. Une équipe qui a évalué plusieurs modèles peut passer de l’un à l’autre en toute confiance.
Mais c’est une décision étayée par des preuves. Un avertissement de capacité ne fournit aucune preuve que l’alternative convient à la tâche qui se présente à moi.
La question pertinente est de savoir si la solution de repli peut satisfaire aux mêmes exigences : comprendre le code existant, préserver ses contrats, gérer les cas limites et produire une modification qui résiste à la revue. Poursuivre la conversation nous renseigne très peu sur le respect de ces exigences.
L’interruption prend fin. Le code reste.
Cela importe, car le code généré peut survivre aux circonstances qui l’ont produit.
Le problème de capacité peut disparaître cet après-midi. Le code écrit pendant celui-ci peut rester en production pendant des années.
Imaginez un développeur changeant de modèle au milieu d’une fonctionnalité. Le remplacement produit un correctif qui semble raisonnable et réussit les tests disponibles. Il est fusionné. Des mois plus tard, un problème de maintenance révèle une hypothèse que personne n’avait examinée avec suffisamment d’attention.
Ce scénario peut se produire avec n’importe quel modèle, y compris le plus capable. La préoccupation supplémentaire est de savoir si l’équipe sait que les conditions dans lesquelles le travail a été généré ont changé.
Pouvons-nous retracer quel modèle et quelle version ont contribué à une modification ? Savons-nous quand un repli s’est produit ? Pouvons-nous relier cette information à la demande de fusion, aux tests et à la revue humaine ? Le repli a-t-il été approuvé pour ce type de travail ?
Enregistrer le modèle ne prouve pas que le code est correct. Cela donne à l’équipe un contexte pour examiner les problèmes et décider où une revue supplémentaire est justifiée.
La disponibilité devrait inclure l’accès au niveau de capacité requis par le flux de travail. Un service peut continuer à fournir des réponses tandis que l’équipe perd confiance dans le fait que ces réponses répondent à ses normes.
Davantage de capacité a un coût physique
La réponse immédiate est évidente : construire davantage de capacité.
Une certaine expansion est nécessaire. Mais les serveurs ont besoin d’électricité. Ils produisent de la chaleur qui doit être gérée. Leur impact carbone dépend de l’approvisionnement électrique, ainsi que de leur fabrication et de l’infrastructure qui les entoure.
Le rapport 2025 de l’Agence internationale de l’énergie sur l’énergie et l’IA a estimé que les centres de données ont consommé environ 415 térawattheures d’électricité en 2024. Son scénario de référence prévoyait environ 945 térawattheures en 2030. Ces chiffres couvrent l’ensemble des centres de données, l’IA étant un moteur important de la croissance projetée.
Ajouter simplement des machines chaque fois que la demande augmente crée une relation de plus en plus exigeante entre l’intelligence et l’énergie. Les entreprises ont besoin d’un service fiable, tandis que le système énergétique doit répondre aux exigences physiques qui le sous-tendent.
Cela place l’efficacité au cœur de la solution. Dans le scénario de haute efficacité de l’AIE, des améliorations plus importantes du matériel et des modèles d’IA réduisent de 20 % la demande d’électricité projetée des centres de données en 2035 par rapport à son scénario de référence. Il s’agit d’un scénario plutôt que d’un résultat garanti, mais il montre pourquoi les choix d’ingénierie comptent.
Un cerveau fonctionne avec environ 20 watts
Le cerveau humain offre un point de référence remarquable.
Sa consommation métabolique est couramment estimée à environ 20 watts. Une étude de 2021 de William Levy et Victoria Calvert, publiée dans les Proceedings of the National Academy of Sciences, examine cette estimation familière et utilise environ 17 watts d’énergie potentielle issue du glucose dans son propre audit.
Le cerveau est un organe coûteux selon les normes biologiques : environ 2 % de la masse corporelle adulte représente près de 20 % de la dépense énergétique au repos. C’est une part inhabituellement importante par rapport à de nombreuses autres espèces. Pourtant, une recherche comparative de Suzana Herculano-Houzel a constaté une consommation énergétique moyenne par neurone globalement similaire chez les rongeurs et les primates étudiés, y compris les humains.
Cela ne nous donne pas un simple ratio d’efficacité entre un cerveau et un système d’IA. Un centre de données sert de nombreux utilisateurs, les tâches diffèrent, et les deux systèmes dépendent d’infrastructures de soutien. L’« intelligence par watt » nécessite une définition de l’intelligence mesurée.
Néanmoins, l’exemple biologique est frappant. L’apprentissage, la perception, le raisonnement et l’adaptation peuvent coexister dans un budget énergétique modeste. Il suggère l’ampleur de la marge dont nous disposons peut-être pour améliorer notre façon de concevoir l’intelligence artificielle.
Une intelligence fiable, fournie efficacement
Pour l’IA d’entreprise, je mesurerais l’efficacité en termes d’énergie par tâche validée et menée à bien. Cela inclut les tentatives échouées, les nouvelles tentatives et le travail de reprise nécessaire pour obtenir un résultat acceptable.
Un modèle plus petit qui accomplit la tâche de manière fiable peut être un excellent choix. Un modèle plus grand peut justifier sa consommation s’il résout un problème qui nécessiterait autrement des tentatives répétées et des corrections importantes. La comparaison utile commence par le travail qui est réellement accompli.
Une meilleure efficacité peut aussi contribuer à soulager la pression sur la capacité : accomplir un travail utile avec moins de ressources crée de la marge pour répondre à une demande plus importante. La fiabilité exige toujours des opérations, des logiciels et une infrastructure solides ; l’efficacité seule n’empêchera pas toutes les pannes.
Mais la direction semble claire. L’IA doit devenir plus capable, plus fiable et moins gourmande en énergie. Les entreprises devraient attendre des progrès sur ces trois plans.
Chaque fois que je lis « Veuillez essayer un autre modèle », cela me rappelle que notre dépendance à l’IA croît plus vite que notre confiance dans sa fourniture.
Le défi du secteur consiste à rendre disponible, lorsque nous en avons besoin, l’intelligence que nous choisissons, à un coût énergétique que nous pouvons soutenir.
