La consommation d’énergie de Claude Code révèle le coût caché des agents IA

La consommation d’énergie de Claude Code a atteint environ 170 kilowattheures lors de l’expérience de huit semaines menée par un chercheur, malgré les gains d’efficacité réalisés dans les infrastructures d’IA modernes.

Le climatologue Zeke Hausfather a suivi 1 138 instructions soumises via l’agent de programmation d’Anthropic. Ces instructions ont déclenché plus de 14 000 appels au modèle et traité 3,2 milliards de tokens. Son estimation centrale correspond à environ 150 wattheures par prompt humain.

Cette estimation est environ 600 fois supérieure au chiffre publié pour l’énergie consommée par un prompt textuel Gemini typique. Ce contraste remet en cause une idée rassurante sur l’intelligence artificielle : qu’un prompt constitue une unité pertinente pour mesurer la consommation.

Un agent IA ne se contente pas de répondre puis de s’arrêter. Il planifie, appelle des outils, lit les résultats, réexamine son contexte de travail et recommence. Une seule requête peut donc initier une longue chaîne de calculs qui reste en grande partie invisible pour l’utilisateur.

C’est le véritable enjeu du récent débat sur l’énergie de l’IA. Google et d’autres fournisseurs ont rendu les réponses individuelles remarquablement efficaces. Dans le même temps, les produits agentiques transforment chaque instruction utilisateur en de nombreuses réponses, appels d’outils et relectures répétées du contexte.

Le résultat ne prouve pas que chaque agent IA gaspille de l’électricité. Il montre que les comparaisons habituelles par prompt ne décrivent plus une catégorie croissante de travail IA. Les développeurs, les acheteurs d’entreprise et les planificateurs d’infrastructure ont désormais besoin de mesures fondées sur les tâches achevées.

La consommation d’énergie de Claude Code change l’unité de mesure

Le changement important n’est pas une nouvelle version de modèle. C’est la preuve qu’un prompt humain peut masquer tout un flux de travail computationnel.

Hausfather a examiné son activité Claude Code du 31 mai au 25 juillet 2026. Claude Code est un système de programmation agentique, ce qui signifie qu’il peut planifier et exécuter une séquence d’actions avec une intervention humaine limitée.

Au cours de ces huit semaines, Hausfather a saisi 1 138 prompts. Ses journaux ont enregistré plus de 14 000 appels distincts au modèle, soit une moyenne d’environ 12 appels pour chaque prompt qu’il a rédigé.

Les sessions ont traité 3,2 milliards de tokens. Les tokens sont les unités qu’un modèle de langage lit et génère lorsqu’il traite du texte, du code, des instructions et du contexte stocké.

Hausfather a estimé que cette charge de travail avait consommé environ 170 kilowattheures d’électricité en centre de données. Sa fourchette d’incertitude s’étendait d’environ 70 à 330 kilowattheures, car Anthropic ne publie pas de mesures directes de l’énergie pour chaque appel au modèle.

L’estimation centrale obtenue était d’environ 150 wattheures par prompt humain. La plage plausible allait de 60 à 290 wattheures.

À titre de comparaison, Google a indiqué qu’un prompt textuel médian dans Gemini Apps consommait 0,24 wattheure dans son environnement de production. Ce chiffre incluait l’alimentation des accélérateurs, les systèmes hôtes, la capacité inactive et les frais généraux du centre de données.

Les mesures de production de Google ne sont pas nécessairement incompatibles avec les calculs de Hausfather. Elles décrivent un type d’activité différent.

Un prompt textuel Gemini peut produire une réponse concise. Une instruction Claude Code peut lancer une session impliquant de la recherche, la génération de code, l’exécution de commandes, le débogage et des évaluations répétées.

Cette distinction explique pourquoi Hausfather soutient qu’un prompt ressemble davantage à un trajet qu’à une distance fixe. Compter les trajets apprend peu à un analyste s’il ne sait pas également où chacun d’eux s’est déroulé.

Sa session Claude Code médiane a consommé environ 0,6 kilowattheure. La plage plausible allait de 0,25 à 1,2 kilowattheure. Sa journée de travail moyenne atteignait environ 3,0 kilowattheures.

La journée la plus intensive a atteint une estimation centrale de 11 kilowattheures. Ce jour-là, plusieurs agents parallèles ont travaillé sur une vaste analyse géospatiale.

Ces chiffres proviennent d’un utilisateur particulièrement intensif, et non d’un échantillon représentatif de tous les clients de Claude Code. Hausfather travaille sur des données climatiques complexes et se décrit comme un utilisateur plus intensif que la plupart des gens.

L’expérience identifie néanmoins une défaillance de mesure qui dépasse le cas d’un seul chercheur. L’utilisateur voit une instruction, tandis que l’infrastructure gère une série ramifiée d’événements computationnels.

Ce changement compte, car les entreprises commercialisent de plus en plus les agents comme des remplaçants de flux de travail complets. Si la promesse du produit concerne le travail achevé, sa comptabilité des ressources devrait également mesurer le travail achevé.

Pourquoi les agents IA consomment plus que les chatbots

Les agents multiplient la demande énergétique par l’itération, le travail parallèle et le traitement répété du contexte, et non par une seule réponse exceptionnelle.

Un échange standard avec un chatbot suit généralement un parcours simple. L’utilisateur envoie du texte, le modèle traite son contexte, puis le système génère une réponse.

Un flux de travail agentique ajoute une boucle de contrôle. Le modèle décide quoi faire, utilise un outil, observe le résultat, met à jour son plan et lance une nouvelle étape d’inférence.

L’inférence est le processus consistant à exécuter un modèle entraîné afin de produire un résultat. Chaque étape d’inférence supplémentaire nécessite des processeurs, de la mémoire, des réseaux et les équipements de centre de données associés.

Claude Code peut rechercher dans un dépôt, lire des fichiers, modifier du code, exécuter des tests, examiner des erreurs et réviser son travail. Une tâche difficile peut impliquer des dizaines ou des centaines de ces étapes.

Les sous-agents parallèles augmentent encore ce nombre. Ils peuvent explorer simultanément des approches distinctes, améliorant la couverture tout en consommant des ressources de calcul au même moment.

Les journaux de Hausfather ont révélé que la sortie visible ne représentait qu’environ 0,4 % de l’ensemble des tokens traités. Environ 96 % correspondaient à des lectures de cache.

Un cache stocke un contexte de modèle précédemment traité afin que le système puisse le réutiliser plus efficacement. La lecture d’un contexte mis en cache coûte moins cher que le traitement de nouvelles entrées, mais elle consomme tout de même des ressources.

Le volume devient important parce qu’un agent revient régulièrement sur l’historique croissant de son travail. Chaque résultat d’outil, extrait de fichier, instruction et décision antérieure peut rester intégré aux appels ultérieurs du modèle.

Cela crée un schéma cumulatif. Les sessions plus longues génèrent davantage de contexte, et les étapes ultérieures peuvent devoir relire une grande partie de ce contexte avant de produire une nouvelle action.

Hausfather a supposé que les tokens mis en cache consommaient 10 % de l’énergie nécessaire pour de nouvelles entrées. Il a également calculé des scénarios bas et hauts en utilisant 1 % et 25 %.

Cette large fourchette montre pourquoi l’estimation finale demeure incertaine. Les prix peuvent fournir des indices sur l’utilisation des ressources, mais un prix réduit par token n’est pas un compteur électrique direct.

Hausfather a testé trois méthodes d’estimation publiées et obtenu des résultats dans la fourchette plus large de 70 à 330 kilowattheures. Cette concordance étaye sa conclusion générale sans éliminer l’incertitude.

Le mécanisme principal apparaît également dans des recherches plus larges sur les émissions. Un cadre comptable de 2026 estime qu’un flux de travail agentique effectuant 5 à 50 appels à un modèle de pointe peut consommer 50 à 500 wattheures.

Le même cadre avertit qu’une interaction peut sous-estimer le calcul sous-jacent d’un ordre de grandeur ou plus. Cet avertissement s’applique directement aux agents présentés via une interface de chat simple.

La gestion du contexte devient donc une décision d’infrastructure, et non une simple fonctionnalité d’utilisabilité. Les équipes peuvent réduire le traitement inutile en limitant le contexte non pertinent et en orientant la récupération vers les informations nécessaires à chaque étape.

Une base de connaissances consultable soigneusement maintenue peut aider les ingénieurs à récupérer des informations ciblées plutôt que de charger à répétition de larges collections de documents. Toutefois, les économies réelles dépendent de l’architecture de l’agent.

Le routage des modèles compte également. Un système peut confier la classification, l’extraction et les modifications de routine à des modèles plus petits, tout en réservant les modèles de pointe au raisonnement difficile.

Cette approche ne supprime pas le coût énergétique de l’agent. Elle aligne la quantité de calcul sur la valeur et la difficulté de chaque opération.

Une IA efficace face à l’expansion des flux de travail agentiques

La tension centrale est que chaque inférence devient moins coûteuse, tandis que les produits agentiques consomment davantage d’inférences pour mener chaque mission à bien.

Le chiffre de 0,24 wattheure de Google apporte des preuves solides que l’optimisation de production peut réduire l’énergie par réponse. L’entreprise a mesuré un prompt textuel Gemini médian sur l’ensemble de sa pile de service, plutôt que de tester un accélérateur isolé.

Google a également signalé une réduction par 33 de l’énergie par prompt médian en un an. Les changements de modèles, les améliorations logicielles, les mises à niveau matérielles et l’optimisation du service ont contribué à cette baisse.

Ces progrès comptent. Des estimations statiques fondées sur des puces plus anciennes ou des systèmes de laboratoire peu utilisés peuvent surestimer considérablement l’électricité nécessaire à un service de production moderne.

Le traitement par lots permet à l’infrastructure de servir plusieurs requêtes ensemble. La mise en cache évite de répéter certains calculs. Une utilisation plus élevée répartit la consommation des équipements inactifs sur davantage de travail utile.

Les processeurs spécialisés effectuent également davantage de calculs pour chaque unité d’électricité. Hausfather a cité des estimations montrant des gains majeurs d’efficacité du matériel d’apprentissage automatique depuis 2016.

Pourtant, l’efficacité par opération ne réduit pas automatiquement la consommation totale. Des calculs moins chers peuvent encourager les développeurs à en utiliser davantage.

Les produits agentiques rendent cet effet rebond visible. Dès lors qu’un appel au modèle devient plus rapide et moins coûteux, les concepteurs peuvent ajouter des passes de planification, des boucles de vérification, l’usage d’outils et des agents parallèles.

Ces ajouts peuvent améliorer le résultat. Ils peuvent aussi consommer le gain d’efficacité avant qu’il ne réduise la demande totale en électricité.

Il s’agit d’une version de l’effet Jevons, selon lequel une meilleure efficacité dans l’usage d’une ressource peut stimuler suffisamment de nouvelle demande pour compenser les économies attendues. L’IA ne garantit pas ce résultat, mais ses incitations actuelles favorisent davantage de calcul.

Les fournisseurs de modèles rivalisent sur l’achèvement des tâches, les performances de programmation et l’autonomie. Les utilisateurs remarquent généralement si l’agent résout le problème, et non le nombre d’appels invisibles nécessaires.

La propre analyse d’usage d’Anthropic a révélé que 77 % des usages professionnels de son API propriétaire dans l’échantillon suivaient des schémas orientés vers l’automatisation. Les tâches de programmation et de bureau y occupaient une place importante.

Cette recherche ne mesurait pas la consommation d’électricité. Elle montre toutefois pourquoi les charges de travail agentiques méritent de l’attention : l’usage des API en entreprise privilégie déjà l’exécution automatisée plutôt que la conversation isolée.

Les incitations économiques renforcent ce schéma. Anthropic a signalé une faible sensibilité aux prix parmi les tâches professionnelles de son échantillon. Les tâches plus capables et plus coûteuses semblaient plus fréquentes que les tâches moins chères.

Si un agent de programmation permet d’économiser plusieurs heures de travail qualifié, une entreprise peut accepter bien plus d’inférences qu’une réponse de chat ne l’exige. L’électricité par prompt devient alors moins utile que l’électricité par problème résolu.

La même logique s’applique à l’analyse scientifique. La journée la plus intensive de Hausfather a soutenu un projet géospatial complexe, et non une conversation informelle.

La comparaison pertinente n’oppose donc pas toujours un agent à un chatbot. Elle peut opposer un flux de travail assisté par un agent aux ordinateurs, aux déplacements, au travail humain ou aux délais nécessaires dans le processus précédent.

Cependant, cette comparaison plus large nécessite des données réelles. Les gains de productivité ne peuvent pas simplement être supposés, et les fournisseurs ne devraient pas utiliser des bénéfices potentiels pour éviter de divulguer la consommation de ressources.

L’efficacité et la croissance des charges de travail doivent être présentées ensemble. Une baisse de la consommation par token peut coexister avec une hausse de la demande d’électricité si le traitement total de tokens augmente plus vite.

C’est pourquoi l’estimation de la consommation énergétique de Claude Code sert d’avertissement plutôt que de verdict définitif. Elle montre à quel point un bon récit d’efficacité peut passer sous silence l’expansion qui se produit au-dessus de la couche du modèle.

Ce que l’estimation de Claude Code ne peut pas prouver

La comparaison par un facteur 600 est importante sur le plan directionnel, mais elle ne constitue pas une mesure directe de la consommation d’électricité d’Anthropic.

Hausfather disposait de journaux d’activité inhabituellement détaillés. Ils enregistraient les identifiants des modèles, les horodatages et les catégories de tokens pour les réponses API individuelles.

Ces journaux fournissent un solide relevé de l’activité de calcul. Ils ne révèlent pas la puissance électrique réellement utilisée par les serveurs d’Anthropic pour chaque requête.

L’estimation convertit donc les tokens en énergie à l’aide de méthodologies publiées. Chaque méthode exige des hypothèses sur le matériel, le taux d’utilisation, le traitement par lots, la gestion du cache et la surcharge des centres de données.

Anthropic n’a pas publié les données énergétiques par token ou par prompt nécessaires pour remplacer ces hypothèses par des mesures de première main. Les emplacements et les sources d’électricité qui ont servi les sessions restent également inconnus.

Le traitement du cache crée une autre incertitude majeure. Un token mis en cache évite de répéter une partie du travail, mais les économies exactes dépendent du système de service.

Le scénario central de Hausfather considérait que les lectures depuis le cache consommaient 10 pour cent de l’énergie d’une entrée nouvelle. Une relation différente modifierait considérablement l’estimation totale.

L’échantillon représente également une seule personne sur huit semaines. Hausfather a utilisé de nombreux sous-agents pour de grandes tâches d’analyse, de sorte que son activité est très éloignée d’une session de programmation d’un utilisateur occasionnel.

Sa session médiane impliquait environ 10 millions de tokens et plus de 100 appels. D’autres estimations publiées pour les sessions Claude Code ont retenu des charges de travail plus modestes.

Il serait donc trompeur d’affirmer que chaque prompt Claude Code consomme 150 watt-heures. La conclusion correcte est plus limitée : certaines sessions agentiques avancées consomment des centaines de fois plus d’énergie que de simples prompts de chat.

La comparaison avec Gemini recoupe également des fournisseurs et des types de charges de travail différents. Le chiffre de Google couvre le prompt textuel médian sur Gemini Apps, tandis que l’estimation de Hausfather porte sur une activité intensive de Claude Code.

Cette différence est précisément l’objet de la comparaison, mais elle limite ce que le ratio peut établir. Elle ne montre pas que Claude est intrinsèquement moins efficace que Gemini.

Seuls des tests contrôlés de tâches comparables sur les deux systèmes pourraient étayer cette affirmation. Dans l’idéal, les fournisseurs publieraient des mesures fondées sur des périmètres système cohérents.

Le cadre de Watershed illustre à quel point ces périmètres influencent les résultats. Il a constaté que des benchmarks isolés peuvent surestimer de quatre à 20 fois l’électricité consommée par l’inférence en production, parce qu’ils ne tiennent pas compte du traitement par lots et de la mise en cache.

L’erreur inverse est également possible. Ne déclarer que la puissance des accélérateurs actifs peut omettre les serveurs hôtes, la capacité inactive, le refroidissement, le réseau et les pertes de conversion électrique.

Les entreprises devraient divulguer à la fois des informations sur les charges de travail et sur l’infrastructure. Parmi les champs utiles figureraient les tokens, la catégorie de modèle, le type d’accélérateur, la surcharge du centre de données, les hypothèses d’utilisation et les sources régionales d’électricité.

Le reporting des tâches achevées ajouterait une autre couche essentielle. Un agent peut utiliser davantage d’énergie par tentative tout en exigeant moins de nouvelles tentatives humaines ou en réalisant un travail que des systèmes plus simples ne peuvent pas mener à terme.

Les taux de réussite comptent, car les exécutions d’agents qui échouent consomment elles aussi de l’électricité. Un flux de travail qui se bloque à répétition peut afficher un mauvais résultat énergétique par résultat obtenu, même lorsque chaque appel individuel semble efficace.

Les acheteurs en entreprise devraient demander aux fournisseurs comment ils gèrent les nouvelles tentatives, l’augmentation du contexte, les défaillances d’outils et le routage des modèles. Ces choix de conception influencent à la fois les coûts d’exploitation et le reporting environnemental.

La position sceptique ne consiste pas à dire que l’estimation de Hausfather devrait être ignorée. Elle consiste à reconnaître qu’une estimation transparente révèle l’ampleur des informations cruciales que les fournisseurs continuent de retenir.

La pression se déplace des utilisateurs vers les acheteurs d’infrastructure

Le problème énergétique des agents sera déterminé davantage par les achats, l’architecture logicielle et l’approvisionnement électrique que par la retenue individuelle dans l’usage des prompts.

Hausfather a extrapolé sa charge de travail de huit semaines à environ 1,1 mégawattheure d’électricité de centre de données. Sa fourchette allait de 0,4 à 2,2 mégawattheures.

En utilisant les émissions moyennes du réseau électrique américain, il a estimé environ 370 kilogrammes d’émissions annuelles en équivalent dioxyde de carbone. La fourchette allait de 150 à 730 kilogrammes.

C’est significatif pour un seul utilisateur de logiciels, mais Hausfather ne soutient pas que la culpabilité individuelle offre la solution principale. Les gros utilisateurs d’agents représentent encore une part limitée de la demande totale d’électricité.

Le risque plus important vient de l’échelle. Une entreprise peut déployer des milliers d’agents fonctionnant en continu dans le développement logiciel, le service client, la finance, la recherche et le travail administratif.

Chaque agent peut générer une demande modeste. Des charges de travail persistantes, multipliées à travers de nombreux services, peuvent modifier les besoins en infrastructures.

Les prévisions pour les centres de données montrent déjà l’ampleur du défi environnant. La mise à jour de 2025 du Lawrence Berkeley National Laboratory estime un scénario de référence pour 2030 à 649 térawattheures pour les centres de données américains.

Ce scénario de référence équivaut à 11,8 pour cent de la consommation totale d’électricité des États-Unis. La fourchette d’incertitude cumulée du rapport s’étend de 521 à 843 térawattheures.

La prévision couvre toute la demande des centres de données, et pas uniquement les agents d’IA. Les serveurs d’IA et leurs taux d’utilisation constituent néanmoins des incertitudes centrales du modèle.

Cela exerce une pression sur trois groupes.

Les fournisseurs de cloud et de modèles doivent divulguer suffisamment d’informations pour que les clients puissent comparer les systèmes. Sans reporting cohérent, l’efficacité devient une affirmation marketing plutôt qu’une métrique d’achat.

Les développeurs d’applications doivent décider à quel moment l’autonomie justifie des appels répétés aux modèles. Un flux de travail à cinq agents devrait être soumis à un seuil de valeur plus élevé qu’une requête unique à un modèle plus petit.

Les acheteurs en entreprise doivent mesurer les résultats. Ils ont besoin du coût, de l’énergie, de la latence et du taux de réussite associés à une tâche achevée, et non à un prompt moyen.

Ces décisions influencent aussi la planification des réseaux électriques. Les grands centres de données nécessitent de la production, des lignes de transport, des sous-stations, des systèmes de refroidissement et une capacité garantie capable de répondre à la demande de pointe.

L’emplacement compte, car une même charge de travail peut produire des émissions différentes selon les systèmes électriques. Une production bas carbone réduit les émissions, même lorsque le calcul sous-jacent reste constant.

La flexibilité des charges de travail peut aider. Certaines tâches d’entraînement, d’évaluation et d’agents en arrière-plan peuvent être déplacées vers des heures ou des régions où l’électricité est plus propre ou moins contrainte.

Les sessions de programmation interactives offrent moins de flexibilité, car les utilisateurs attendent des réponses rapides. Toutefois, la recherche ou les tests non urgents effectués par des sous-agents peuvent tolérer une planification.

Les modèles plus petits offrent un autre levier. La classification de routine, la sélection de fichiers et les vérifications syntaxiques ne nécessitent pas toujours le plus grand modèle disponible.

Les développeurs peuvent également limiter les itérations, compresser le contexte, réutiliser les résultats validés et interrompre plus tôt les flux de travail défaillants. Ces contrôles peuvent réduire les coûts tout en améliorant la prévisibilité.

La meilleure architecture n’utilisera pas toujours le moins d’électricité. Elle devrait utiliser le moins de calcul nécessaire pour achever de manière fiable la tâche à forte valeur.

Cette norme relie la performance environnementale à la rigueur d’ingénierie. Les nouvelles tentatives inutiles, les contextes surdimensionnés et les appels superflus à des modèles de pointe sont généralement aussi des problèmes financiers.

Trois signaux montreront si l’IA agentique peut évoluer de manière responsable

La prochaine phase du débat sur l’énergie de l’IA dépendra de la transparence des fournisseurs, de l’efficacité au niveau des tâches et de l’électricité construite pour les nouveaux centres de données.

Le premier signal est un reporting énergétique direct d’Anthropic et des autres fournisseurs de modèles. Les journaux de tokens ne peuvent pas répondre aux questions nécessitant l’accès au matériel de production et aux données de service.

Une divulgation utile devrait distinguer le chat simple, le raisonnement, le code et les flux de travail multi-agents. Elle devrait couvrir l’infrastructure complète plutôt qu’un seul processeur.

Si les fournisseurs publient des mesures comparables au niveau des tâches, la confiance dans les estimations énergétiques des agents s’améliorera. Un silence persistant renforcera les inquiétudes selon lesquelles les clients ne peuvent pas évaluer les systèmes qu’ils déploient.

Le deuxième signal est de savoir si l’énergie par tâche achevée diminue, et pas seulement l’énergie par token. De meilleures puces et de meilleurs logiciels de service continueront à réduire le coût des opérations individuelles.

Les agents peuvent néanmoins absorber ces gains en utilisant des contextes plus longs et davantage d’appels. Les fournisseurs devraient présenter le succès des tâches parallèlement à l’inférence totale, aux nouvelles tentatives et à la latence.

Une baisse de l’indicateur au niveau des tâches montrerait que l’efficacité dépasse l’expansion des flux de travail. Une consommation croissante pour des résultats similaires suggérerait que l’autonomie supplémentaire absorbe les économies.

Le troisième signal est le type d’électricité associé à la nouvelle capacité des centres de données. L’efficacité ne peut pas déterminer les émissions sans connaître la source de production.

Hausfather estime que faire fonctionner la même charge de travail avec une alimentation électrique largement propre pourrait réduire ses émissions d’environ 90 pour cent. La réduction exacte varie selon le lieu et la méthode d’approvisionnement.

De nouvelles capacités renouvelables, le stockage, l’énergie nucléaire, les ressources géothermiques et le transport d’électricité peuvent réduire l’intensité carbone de la demande supplémentaire. Une production dédiée à partir de combustibles fossiles fait évoluer le système dans la direction opposée.

Ces signaux importent davantage que les débats visant à déterminer si un prompt d’IA équivaut à quelques secondes de télévision. Cette comparaison décrit une interaction étroite que les agents dépassent rapidement.

Une meilleure question est de savoir si un agent a accompli un travail qui valait son coût computationnel total. Pour y répondre, il faut des journaux transparents, des mesures des fournisseurs et un suivi honnête des résultats.

Les développeurs peuvent commencer dès maintenant en auditant le nombre d’appels, la croissance du contexte, les nouvelles tentatives et la sélection des modèles. Les acheteurs en entreprise peuvent demander des données sur les ressources au niveau des tâches lors des achats, plutôt que d’accepter une moyenne unique.

L’estimation de la consommation énergétique de Claude Code ne tranche pas la question de savoir si les agents apportent suffisamment de valeur. Elle établit que leur véritable unité de consommation est le flux de travail.

À mesure que les agents prennent en charge des missions plus longues, les utilisateurs devraient se demander ce qui se passe après avoir appuyé sur Entrée. Combien de modèles sont exécutés, à quelle fréquence relisent-ils le contexte, et quelles sources d’électricité maintiennent ce processus en marche ?