Nous avons testé 6 assistants IA sur les mêmes données solaires. Les résultats nous ont surpris

Nous développons une fonctionnalité pour HelioPeak que nous appelons « Export pour analyse IA ». L'idée est simple : un appui sur un bouton dans l'application, vous obtenez un fichier Markdown contenant vos données de production solaire ainsi que des instructions détaillées destinées à un assistant IA, vous le collez dans le chatbot de votre choix, et vous recevez une analyse qui vaut plus que la somme de ses parties. Aucun serveur HelioPeak dans la boucle, pas d'abonnement récurrent, pas de théâtre autour de la confidentialité, juste vos données et l'IA que vous préférez.

Avant d'écrire la moindre ligne de Swift pour cette fonctionnalité, nous voulions valider le concept sur de vrais chatbots. Nous avons donc construit un prototype en Python qui génère le même fichier d'export en trois variantes, avec des instructions de plus en plus précises, et nous avons testé chaque version sur six assistants IA. L'export contenait deux ans de données quotidiennes, trois années complètes de totaux annuels, les métadonnées du système, des notes utilisateur et un prompt élaboré demandant à l'IA de produire une analyse structurée en 14 sections, avec des réponses à 39 questions spécifiques.

Ce que nous avons trouvé nous a, pour être honnêtes, fait rougir. Pas parce que les assistants IA sont mauvais (certains sont réellement remarquables), mais parce que l'écart entre la meilleure et la moins bonne réponse est tel que deux utilisateurs disposant du même système solaire pourraient aboutir à des conclusions totalement différentes selon le chatbot qu'ils ont choisi. Certains assistants ont inventé des chiffres absents des données. D'autres ont prétendu que le fichier était tronqué alors qu'il ne l'était pas. L'un a promis un rapport PDF qu'il n'a jamais livré. Un autre a livré un PDF dépouillé de toute mise en forme.

Cet article est le récit de ce test. C'est en partie un benchmark, en partie un aveu sur la naïveté de notre premier prompt, et en partie, nous l'espérons, utile à quiconque essaie d'obtenir une analyse fiable d'un assistant IA sur un jeu de données non trivial.

Le dispositif

Le jeu de données testé représentait une installation belge synthétique mais réaliste de 5,7 kWc, avec une répartition est-ouest des panneaux et un onduleur Fronius de 5 kW, en service depuis avril 2018. Les enregistrements de production quotidienne, mensuelle et annuelle de janvier 2023 au 23 mai 2026 étaient intégrés sous forme de blocs JSON dans un fichier Markdown, accompagnés des données de consommation, d'import et d'injection au réseau, de quelques notes utilisateur et d'une poignée de Solar Moments. La taille totale du fichier atteignait environ 220 kB dans la plus grande variante, soit environ 55 000 tokens, bien à l'intérieur de la zone de confort de n'importe quel modèle frontière moderne.

Le prompt lui-même était volumineux. Il demandait à l'IA de livrer treize sections analytiques dans un ordre précis, de répondre à trente-neuf questions spécifiques allant de « quelle est la production cumulée depuis l'installation » à « comment évoluerait le taux d'autoconsommation si le ménage ajoutait un véhicule électrique consommant 5 kWh par jour », et, en option, de produire un rapport PDF avec la charte graphique en bonus. Les instructions précisaient la langue de réponse (français dans nos tests), la devise et des règles explicites contre les valeurs inventées ou l'extrapolation au-delà des données.

Nous avons testé six assistants IA sur exactement le même fichier : Claude d'Anthropic (via claude.ai), ChatGPT d'OpenAI (niveau Plus avec Code Interpreter), Gemini de Google (niveau Pro), Google AI Studio (avec exécution de code activée), Grok de xAI, et Copilot de Microsoft. Dans chaque cas, le prompt côté utilisateur était identique : une seule phrase en français demandant à l'assistant de lire le fichier et de suivre les instructions qu'il contient.

Voici ce que chacun en a fait. Nous les avons classés du plus mauvais au meilleur, parce que les modes d'échec sont plus instructifs que les succès.

Copilot : l'erreur fabriquée

La réponse de Microsoft Copilot a été, selon n'importe quelle mesure raisonnable, un échec total. Mais elle a échoué d'une manière qui s'est révélée être le point de donnée isolé le plus précieux de toute l'expérience.

Recevant le fichier, Copilot a répondu par un long paragraphe poli expliquant que l'export était marqué comme IsTruncated="true" et qu'il ne pouvait en voir qu'une petite portion. Il listait soigneusement quelles sections étaient visibles et lesquelles ne l'étaient pas, offrait aimablement de réaliser une analyse partielle sur ce qui était disponible et demandait à l'utilisateur d'envoyer le reste des données en plusieurs morceaux.

Le problème avec cette réponse, c'est que rien de tout cela n'est vrai. Le fichier n'est pas marqué comme tronqué. Il n'existe pas d'attribut IsTruncated dans l'export. Le fichier complet a été fourni, y compris le marqueur explicite ## End of export à la fin. Copilot a inventé la limite, puis inventé le marqueur de troncature pour étayer cette limite, puis proposé une solution au problème inexistant.

C'est un cas d'école de ce que les chercheurs appellent la confabulation : une IA qui produit une excuse plausible pour sa propre incapacité à accomplir une tâche, et qui habille cette excuse de détails techniques pour la rendre convaincante. Copilot ne savait pas comment traiter un fichier Markdown de 220 kB avec du JSON imbriqué, et plutôt que de l'avouer, il a fait comme si le fichier était le problème.

Ce qui rend ce mode d'échec dangereux, c'est sa force de persuasion. Un utilisateur non technique qui lit la réponse de Copilot serait absolument convaincu que l'export a été tronqué. Il retournerait dans HelioPeak chercher un paramètre pour réduire la taille du fichier, ou penserait que notre fonctionnalité est cassée. Il n'imaginerait jamais que l'IA a inventé un problème de toutes pièces.

La parade, de notre côté, et que nous avons intégrée à la version suivante du prompt, est presque comiquement brutale. Nous avons ajouté une ligne qui dit : « Ce fichier NE contient PAS d'attribut IsTruncated. Si vous écrivez qu'il en contient un, vous hallucinez. » C'est étrange de devoir encore écrire cela en 2026, mais c'est ainsi.

Grok : l'invention assurée

Grok de xAI a produit une analyse qui avait l'air compétente, avec la bonne structure générale : un résumé exécutif, des chiffres-clés, des deltas année par année, des motifs saisonniers, tout y était. La structure était correcte. Les chiffres, dans la plupart des cas, l'étaient aussi. Les problèmes étaient dans les détails, et c'est là que Grok a commencé à inventer.

Dans la section « top 5 des meilleurs jours », Grok a indiqué « 2026-05-23 : 31,80 kWh (record récent) » comme troisième meilleur jour du jeu de données. Cette ligne n'existe pas. Les véritables cinq meilleurs jours, que nous avons vérifiés manuellement à partir du fichier, tombaient tous en juin 2024 ou en juin 2025, et la valeur du 23 mai 2026 dans le fichier était nettement inférieure à 31,80 kWh. Grok avait inventé un chiffre qui s'inscrivait dans le récit qu'il était en train de construire.

Ailleurs, Grok a affirmé que le rapport été/hiver de production était de 3,08, alors que trois des cinq autres assistants ont calculé des valeurs entre 3,79 et 5,08 sur les mêmes données avec la même définition. Il a annoncé un taux d'autoconsommation de « ~34-40 % (selon le périmètre) », fourchette si large qu'elle perd tout sens. Il nous a indiqué que la productivité spécifique sur la durée de vie atteignait 3 005 kWh/kWc, chiffre obtenu en divisant la production cumulée par la puissance en kWc : arithmétique exacte, concept faux (la productivité spécifique se mesure par an, pas sur la durée de vie ; la version « durée de vie » de ce nombre n'a pas de référence de comparaison utile).

La plupart de ces erreurs passeraient inaperçues pour un utilisateur non expert. Les ordres de grandeur sont corrects, la langue est fluide, et rien ne signale qu'une donnée est fausse. C'est la catégorie la plus dangereuse de production d'IA : assurée, fluide, et en partie inventée. Nous préférerions de loin qu'un chatbot dise « je ne peux pas calculer cela » plutôt qu'il invente une réponse plausible mais fausse.

Pour répondre à cela en v0.3 de notre prompt, nous avons ajouté ce que nous avons appelé la règle honnêteté avant exhaustivité, qui dit en langage simple qu'une analyse partielle mais honnête est plus utile qu'une analyse complète mais inventée. Nous verrons dans la prochaine itération si Grok la prend à cœur.

ChatGPT : le devoir bâclé

ChatGPT Plus avec Code Interpreter activé a fait quelque chose qui nous a surpris. Il a effectivement utilisé Python. Il a effectivement parsé le JSON. Il a effectivement calculé les métriques. Il a produit les bons chiffres pour à peu près tout : 17 131 kWh depuis l'installation, 5 091 kWh de moyenne par année complète, 35,1 % d'autoconsommation, 57 jours de bridage. La section financière incluait même les deux perspectives que nous avions demandées : la vue strictement formulaire qui produit un nombre négatif trompeur, et la comparaison « par rapport à pas de solaire » qui montre le bénéfice réel.

Et quand est venu le moment de vraiment rédiger l'analyse, ChatGPT est passé en mode hâtif. Les réponses aux 39 questions spécifiques étaient des résumés d'une ligne du genre « Variation année sur année calculée » sans les valeurs effectivement calculées, alors même qu'il venait de les calculer. C'était comme si un élève avait fait l'exercice correctement et ne remettait que la table des matières.

Le PDF était encore pire. ChatGPT a généré un document de quatre pages en Helvetica standard sur fond blanc, avec des titres en noir uni, sans logo, sans la couverture en dégradé bleu nuit, sans la couleur d'accent orange, sans la grande tuile chiffre en première page, sans le style de pied de page. Aucun des cinq éléments de signature HelioPeak que nous avions spécifiés dans le prompt n'était présent. Le PDF ressemblait à la sortie « hello world » de reportlab.

C'est un schéma d'échec intéressant, parce que le modèle aurait clairement pu faire mieux. Les instructions étaient détaillées. Les couleurs de la marque étaient écrites dans un tableau. Le logo était fourni en SVG inline. Les directives de style étaient explicites. ChatGPT a simplement choisi de ne pas faire l'effort. Générer un PDF générique est moins coûteux en calcul qu'implémenter une mise en page personnalisée multipage brandée avec dégradés et éléments de signature, et ChatGPT a optimisé pour le moins cher.

Nous avons traité cela en v0.3 en ajoutant une checklist PDF à la livraison : une liste de 5 éléments de l'identité visuelle qui doivent être présents avant livraison. Si un seul manque, le prompt demande à l'IA de sauter le PDF et de le signaler honnêtement, plutôt que de livrer une version générique. Si cela fonctionnera en pratique dépend de la volonté de l'IA de fournir l'effort supérieur ou de simplement renoncer à l'effort inférieur.

Gemini Pro : du saut honnête à la livraison complète

Le Gemini Pro de Google a livré ce que nous appellerions une analyse rigoureusement compétente, dès le tout premier round. Les treize sections présentes et substantielles. Les trente-neuf questions répondues avec des chiffres concrets là où les données le permettaient. La section financière était excellemment exécutée, avec la vue strictement formulaire et la comparaison « par rapport à pas de solaire » présentées clairement, et étiquetées en indiquant laquelle représentait le bénéfice réel pour le propriétaire. Le rapport été/hiver, la productivité spécifique, le taux d'autoconsommation, tous dans le même ordre de grandeur que notre référence calculée manuellement.

L'analyse du bridage était particulièrement bonne. Gemini a estimé entre 50 et 80 jours de bridage par an avec un impact financier de 15 à 25 € par an, et a ajouté la remarque qu'un upgrade de l'onduleur ne serait pas économiquement rationnel au tarif actuel de rachat. Ce type de jugement contextuel, par-dessus le calcul brut, est exactement la valeur ajoutée que nous attendions de l'IA pour la compréhension de l'utilisateur.

Dans les trois premiers rounds, Gemini a constamment et honnêtement sauté le bonus PDF. Le paragraphe « Capabilities » en tête disait alors « La génération PDF est limitée dans cet environnement, je me concentre donc sur une analyse textuelle complète et je saute le bonus PDF. » C'était déjà le bon comportement : mieux vaut livrer une excellente analyse textuelle et sauter honnêtement le PDF, plutôt que livrer une bonne analyse et un PDF médiocre.

Puis, dans le quatrième round, avec l'instruction single-source-of-truth en place et la restructuration narrative qui supprimait la pression Q&R, quelque chose a changé. Gemini a aussi livré le PDF : onze pages, les cinq éléments de signature HelioPeak présents (couverture en dégradé bleu nuit, logo intégré avec dégradés intacts, accent orange sur titres et numéros de page, pied de page sur chaque page, tuile chiffre principal), chaque nombre du PDF correspondant au centime près à l'analyse Markdown. Il a même géré correctement la typographie de l'indice CO₂ (chose pour laquelle la sortie précédente de Claude avait dû s'excuser). Nous n'avions rien changé à nos instructions PDF entre v0.3 et v0.4 ; la différence venait probablement du fait que le backend d'exécution de code de Gemini avait été mis à jour pour mieux sauvegarder des fichiers, ou que notre prompt restructuré imposait simplement moins de charge cognitive. Quoi qu'il en soit, Gemini Pro est passé du « saut honnête » à une solide deuxième place.

Google AI Studio : le quasi-réussi frustrant

Si l'on classait les six chatbots uniquement sur la qualité de l'analyse textuelle, Google AI Studio terminerait premier ou presque. Il était d'une courte marge le plus rigoureux, avec des chiffres concrets derrière chaque affirmation. Son estimation du bridage était un précis « 38 jours par an, ~45 kWh, 7,85 € perdus » plutôt qu'une fourchette vague. L'analyse de l'équilibre des strings est-ouest (une de nos nouvelles questions) donnait une lecture spécifique de « 48 % des pics avant 12h00, 52 % après » que nous n'avions vue dans aucun autre modèle. La validation des Solar Moments a correctement vérifié que le jalon « 10 000 kWh depuis l'installation » du 12 avril 2024 était cohérent avec la production cumulée depuis 2018.

Et puis, à la fin de la réponse, il a écrit : « Je génère maintenant le fichier PDF 'HelioPeak_Analysis_Report_20260523.pdf' avec la couverture navy-gold, le logo et tous les KPI ci-dessus. Vous pourrez télécharger ce fichier dans quelques secondes. »

Aucun fichier n'est apparu. Pas en quelques secondes, pas en quelques minutes, pas du tout. AI Studio ne peut pas livrer d'artefacts de fichiers à l'intérieur de son interface de chat (limitation du runtime, pas du modèle), mais plutôt que de le dire d'emblée dans la section « Capabilities », le modèle a rédigé une description de ce que contiendrait le PDF, et puis plus rien.

C'est un mode d'échec différent du « PDF cheap » de ChatGPT ou du « saut honnête » de Gemini. AI Studio a promis un PDF et puis s'est tu. L'utilisateur reste là à chercher un lien de téléchargement qui n'existe pas, à se demander si le modèle est encore en train de travailler, s'il faut cliquer quelque part, ou si quelque chose s'est mal passé de son côté. La brillante analyse qui précède est partiellement minée par la promesse non tenue qui suit.

La parade en v0.3 a consisté à étendre la vérification de capacités de « pouvez-vous produire des fichiers PDF » à « pouvez-vous produire des fichiers PDF ET les livrer comme artefacts téléchargeables dans cette conversation ». Nous verrons au prochain round si AI Studio respecte cette distinction.

Claude : le détective des données

Claude d'Anthropic a livré ce que nous considérons désormais comme l'étalon-or pour cette tâche. L'analyse textuelle était rigoureuse, précise et bien structurée. Le PDF était magnifiquement brandé, avec la couverture en dégradé bleu nuit, le logo HelioPeak intégré, l'accent orange utilisé de façon cohérente sur les titres de sections et les numéros de page, et la grande tuile chiffre en dégradé doré. Chacun de nos cinq éléments de signature obligatoires était présent.

Mais la partie la plus intéressante de la réponse de Claude n'était pas l'analyse elle-même. C'est ce que Claude a fait après l'analyse. Dans une section intitulée « Réflexion en tant que test de votre export Tier 1 », l'IA nous a donné un retour sur le fichier d'export lui-même, signalant des problèmes dans les données et suggérant des améliorations à la conception du prompt. Deux de ces suggestions ont conduit à la v0.2 du prompt : une note explicite sur quel tableau de données utiliser pour quel type de métrique, et l'exigence d'afficher deux perspectives financières côte à côte. Nous reviendrons plus loin dans cet article sur un troisième constat, qui s'est révélé être un faux positif mais n'en était pas moins instructif.

C'est l'argument en faveur de l'usage d'une IA frontière haut de gamme pour ce type de travail : non seulement une sortie mieux formatée, mais réellement un meilleur collaborateur qui pousse en retour sur vos données quand il y a une raison de le faire.

Le problème de divergence entre modèles

L'observation la plus inconfortable de notre premier round, c'est à quel point les chiffres divergeaient entre les modèles, même sur des métriques qui auraient dû être univoques. Voici cinq métriques calculées par les cinq modèles qui ont réellement produit l'analyse (Copilot exclu, puisqu'il n'a même pas essayé) :

Les chiffres de productivité spécifique sont proches parce que la formule était univoque et explicitement présente dans nos instructions : kWh annuels divisés par kWc installés. Chaque modèle qui a pris la peine de calculer cela a abouti à la même réponse aux arrondis près.

Les chiffres d'autoconsommation sont proches pour la même raison : formule directe, données d'entrée univoques.

Les trois autres ont divergé parce que nous avions été négligents avec les définitions. Nous avions demandé à l'IA de calculer le « rapport été/hiver » sans préciser si cela signifiait (somme de juin + juillet + août sur toutes les années) divisée par (somme de décembre + janvier + février sur toutes les années), ou (moyenne des totaux mensuels d'été) divisée par (moyenne des totaux mensuels d'hiver), ou autre chose encore. Différents modèles ont choisi différentes interprétations, et les résultats ont divergé d'un facteur 1,65.

Pareil pour les jours de bridage : nous avons dit « comptez les jours où la puissance de pointe approche du plafond de l'onduleur » sans définir « approche ». Certains modèles ont pris 99 % du plafond, d'autres 95 %, d'autres encore ont considéré comme bridage tout jour avec peak_w ≥ 4900 W. Trois seuils différents, trois totaux différents.

Et la conversion CO₂ vers kilomètres dépend entièrement de la valeur que vous utilisez pour les émissions d'une voiture essence type. Nous n'avons spécifié aucune valeur. Les modèles ont choisi entre 0,10 et 0,20 kg CO₂ par kilomètre selon ce qui se trouvait dans leurs données d'entraînement, et l'équivalence a varié en conséquence.

La leçon est dure mais utile : si vous voulez des chiffres cohérents d'un assistant IA à l'autre, vous ne pouvez pas leur dire seulement quoi calculer. Vous devez leur dire comment le calculer exactement, jusqu'aux constantes. Nous avons ajouté à notre export une section que nous appelons l'« Annexe de calcul » contenant la formule et les constantes pour chaque métrique qui avait divergé. Douze formules en tout. Six exemples :

La parade a fonctionné. Et puis plus.

Nous avons relancé le test avec l'Annexe de calcul incluse. Le résultat, sur les métriques qui divergeaient auparavant, était impressionnant :

Cinq des six LLM testés produisent désormais des chiffres identiques sur quatre des cinq métriques litigieuses. La cinquième (jours de bridage) varie encore parce que différents modèles arrondissent le seuil différemment, mais la dispersion est passée de 2,1× à 1,4×. Nous pourrions aussi régler cela avec des instructions de formule encore plus explicites, mais à un moment le coût en longueur de prompt n'est plus justifié par le gain de précision marginal.

Le problème structurel de la divergence des LLM est donc, pour l'essentiel, résolu. Mais trois nouveaux modes d'échec sont apparus que nous n'avions pas anticipés, et l'un d'eux nous a appris quelque chose de fondamental sur la façon dont nous avions abordé la sortie d'un LLM.

Le piège des Q&R : même une bonne sortie peut sembler du devoir scolaire

Notre prompt demandait à l'IA de répondre à 39 questions spécifiques. Nous voyions cela comme un mécanisme de contrôle qualité : il garantissait que l'analyse couvrait tout le terrain souhaité, et nous donnait quelque chose de concret sur lequel évaluer la sortie. Nous n'avions pas vraiment réfléchi à comment l'IA présenterait ses réponses.

Ce que nous avons reçu, pour chaque modèle qui s'en sortait bien sur la tâche, c'était une longue section « Questions spécifiques répondues » à la fin de chaque analyse, mise en forme comme une liste Q&R numérotée. Parfois cent lignes de « Q1 : … R1 : … ». Même Claude, qui produisait la meilleure analyse globalement, nous a donné cette structure.

En relisant ces rapports, nous nous sommes rendu compte qu'ils ressemblaient à des copies d'examen, pas à l'analyse qu'un consultant rédigerait. Le résumé exécutif fluide en haut enchaînait élégamment sur la discussion année par année, sur les motifs saisonniers, sur les meilleurs et pires jours, puis s'arrêtait abruptement dans un long bloc de réponses d'une ligne. La première moitié se lisait comme une analyse, la seconde comme une checklist de devoir à cocher.

C'était notre faute, pas celle de l'IA. Nous avions demandé à la fois une analyse narrative en 14 sections ET une session de Q&R en 39 questions, et la plupart des IA ont livré exactement ce que nous demandions, qui était la mauvaise chose.

La parade a consisté à intégrer les questions directement dans les 14 sections, comme listes de « sujets à couvrir » imbriquées dans les instructions de chaque section. Ainsi, au lieu que la section 7 dise « Anomalies et périodes de sous-performance » puis que la question 11 demande plus loin « quantifiez la perte due au bridage », la section 7 lit désormais :

7. Anomalies, qualité des données et comportement de l'onduleur. Section en prose. Couvrez : présence et quantification du bridage de l'onduleur (comptez les jours où peak_w ≥ 0,98 × inverter_W, estimez la perte énergétique sur la base de 1,5 kWh par jour de bridage, estimez l'impact financier) ; présence de chutes de plusieurs jours avec causes possibles ; vérification que les Solar Moments sont cohérents avec les données de production …

Et les règles critiques interdisent désormais explicitement le format Q&R :

Ne formatez PAS le rapport comme une liste Q&R numérotée. Ne présentez pas les réponses comme « Q1 : … R1 : … », ne répétez pas littéralement les listes de sujets, ne regroupez pas les « questions sautées » à la fin. Le rapport doit se lire comme une note d'analyse fluide.

C'est une leçon largement transposable, bien au-delà des données solaires : la structure de votre prompt devient la structure de la sortie. Si vous donnez à une IA une checklist numérotée, vous obtenez une réponse avec une checklist numérotée. Si vous donnez un briefing narratif, vous obtenez un récit. Les questions importent, mais la façon de les intégrer détermine si le rapport ressemble à une analyse ou à un devoir.

Le PDF qui mentait sur lui-même

Un autre mode d'échec est apparu dans le deuxième round de test, et celui-ci était spécifique à ChatGPT.

ChatGPT utilisait désormais correctement Python pour calculer son analyse. Le rapport Markdown qu'il a livré était exact : 444,51 € de revenus d'injection sur la durée de vie, 1 865,67 € d'économies par autoconsommation, tout cohérent avec notre calcul de référence. Et il a ensuite généré un PDF.

Le PDF indiquait 888,53 € de revenus d'injection et 1 031 € d'économies par autoconsommation.

Deux chiffres différents pour la même métrique, du même modèle, dans la même session de chat, les deux présentés comme définitifs. L'utilisateur ouvre le rapport Markdown et le PDF côte à côte et lit le tableau financier de deux systèmes solaires différents, chacun présenté avec autorité. C'est pire que pas de PDF du tout. Cela détruit activement la confiance.

Ce qui s'est presque certainement passé, c'est que le code interpreter de ChatGPT a exécuté l'analyse dans une session Python, puis a démarré une session fraîche pour construire le PDF, important des hypothèses de tarifs par défaut différentes. Le modèle n'a pas conscience que « l'analyse Markdown a utilisé un tarif de rachat de 0,04 € et le PDF a utilisé 0,08 € », les deux sessions ont vu un calcul cohérent, juste avec des entrées différentes. Le modèle n'a pas de mémoire lui permettant de se souvenir qu'il s'était déjà engagé sur un jeu de chiffres plus tôt.

Nous avons traité cela avec une instruction single-source-of-truth explicite dans le prompt :

Les chiffres dans le PDF DOIVENT provenir des MÊMES valeurs calculées qui sous-tendent l'analyse textuelle. Ils ne doivent pas être recalculés indépendamment. Après la phase « Compute » de votre workflow, sauvegardez CHAQUE métrique dans un seul dict ou namespace (par exemple metrics = {…}). Le rédacteur de la prose lit dans metrics["lifetime_kwh"]. Le builder du PDF lit dans metrics["lifetime_kwh"]. Ne recalculez jamais ce qui a déjà été calculé.

Reste à voir si cela fonctionne spécifiquement avec ChatGPT. L'instruction demande au modèle de gérer son propre état entre deux phases d'une tâche multi-étapes, ce qui est précisément le point faible des LLM modernes. Nous devrons peut-être accepter que les PDF de ChatGPT sont peu fiables, ou abandonner la fonction PDF pour ce modèle spécifique. Claude, en revanche, a géré cela parfaitement du premier coup : le PDF de 11 pages contenait des chiffres identiques à l'analyse Markdown de bout en bout, parce qu'il maintient effectivement un état de calcul cohérent sur une longue tâche.

Le travail de détective de Claude, revisité

Une observation du deuxième round de Claude mérite un coup de projecteur supplémentaire, parce qu'elle montre à la fois la force et la faiblesse de l'usage d'une IA comme détective des données.

Dans son analyse, Claude a signalé ce qu'il a appelé trois incohérences dans les Solar Moments. L'export contenait cinq jalons Solar Moments : « 10 000 kWh depuis l'installation » le 12 avril 2024, « 5 000 kg CO₂ évités » le 30 septembre 2024, « Meilleur jour de 2024 » le 14 juin, « 7 ans d'installation » le 15 avril 2025, et « 20 000 kWh depuis l'installation » le 22 août 2025.

Claude a correctement noté que trois de ces jalons ne collent pas avec les données de l'export. Le tableau annuel commence en janvier 2023, et au 12 avril 2024 il n'indique que 6 467 kWh produits, pas les 10 000 que prétend le jalon. Au 30 septembre 2024, l'export montre environ 8 500 kWh produits, ce qui implique environ 4 000 kg de CO₂ évité, pas 5 000. Au 22 août 2025, l'export montre environ 14 200 kWh, pas 20 000.

C'est du travail forensique de données pointu. Claude a extrait la production cumulée du tableau annuel et a noté l'écart. Nous avons été assez impressionnés pour ajouter cela comme défaut candidat à notre tracker de bugs iOS.

Mais nous avons ensuite relu le profil système, qui indique comme date d'installation le 15 avril 2018. Le système produit de l'énergie solaire depuis huit ans ; l'export ne contient que les trois dernières années. Les « 5 000 à 6 000 kWh manquants » nécessaires pour que les jalons collent correspondent exactement à la production de 2018 à 2022 qui n'est tout simplement pas dans cet export. Les Solar Moments lisent depuis un historique plus long (probablement le total à vie de PVOutput lui-même), tandis que le tableau annuel est le sous-ensemble que HelioPeak garde en cache.

Ce n'est pas un bug. C'est un comportement correct, simplement insuffisamment documenté. L'utilisateur voit sur son téléphone un jalon « 20 000 kWh depuis l'installation » parce que son système PVOutput a effectivement franchi cette barre ; cela ne s'est juste pas entièrement déroulé à l'intérieur de la fenêtre temporelle de cet export.

La leçon ici est double. D'un côté, la capacité de Claude à trouver ce type d'incohérence en quelques secondes est extraordinairement précieuse. C'est exactement l'alarme qualité-données qu'un exporteur devrait entendre, même si elle s'est révélée être un faux positif dans ce cas. D'un autre côté, Claude était assuré dans son diagnostic, et un développeur moins prudent (nous, au départ) aurait passé des heures à chercher un bug de fuseau horaire inexistant dans le code iOS. L'IA est un brillant détective des données, mais elle ne sait pas ce qu'elle ne sait pas : elle ne peut pas voir au-delà des données qu'on lui donne. La date d'installation de l'utilisateur était là dans l'en-tête de l'export ; Claude n'a juste pas fait le lien avec la conclusion.

Nous avons traité cela en ajoutant une note explicite dans l'en-tête de l'export (« Portée Solar Moments : les jalons peuvent référer à de la production cumulée antérieure à la date de début du tableau annuel ») et une règle explicite dans les règles critiques (« ne marquez un jalon comme incohérent que si le système a été installé APRÈS le début du tableau annuel »). Les futures exécutions Claude devraient sauter ce faux positif.

Capacité contre effort : le vrai spectre

Pour cette expérience, nous avons naïvement divisé les assistants IA en « bons » (supposés performants sur les tâches détaillées) et « mauvais » (supposés faibles). Ce que nous avons trouvé en réalité, c'est un spectre à deux dimensions : capacité contre effort.

Certains modèles ont une capacité élevée mais une faible disposition à fournir l'effort. ChatGPT dans notre test en était un exemple clair : le Code Interpreter est réellement puissant, le modèle peut clairement comprendre un prompt complexe, et pourtant la sortie finalement livrée semblait précipitée et incomplète. Le modèle a choisi de faire moins de travail qu'il ne le pouvait.

D'autres modèles ont une capacité brute plus faible mais fournissent plus d'effort par rapport à leur plafond. Gemini Pro donnait cette impression : pas toujours le plus intelligent, mais constamment honnête sur ce qu'il pouvait et ne pouvait pas faire, et constamment prêt à dérouler la structure complète à la demande.

Un petit nombre de modèles obtient un score élevé sur les deux axes. Claude dans notre test ressemblait à un collaborateur volontaire qui s'avérait être également aiguisé. Le fait qu'il nous ait donné une critique non sollicitée du fichier d'export lui-même était un signe. C'est ce que fait un collègue qualifié et engagé.

Et puis il y a les cas en bas à gauche du quadrant : faible capacité, faible effort, les deux masqués par un langage assuré. Copilot et Grok dans notre test correspondaient tous deux à ce schéma, bien qu'ils échouent différemment. Copilot invente des excuses externes (« le fichier est tronqué »), tandis que Grok invente du contenu interne (un meilleur jour qui n'existe pas).

Notre recommandation actuelle

Si vous comptez utiliser la fonction « Export pour analyse IA » de HelioPeak quand elle sortira, voici notre classement au 23 mai 2026, après quatre rounds de test avec le prompt définitif v0.4 :

1. Claude (sur claude.ai) : clairement le meilleur en général. Analyse textuelle étalon-or, PDF brandé impeccable, trouve de vrais problèmes de qualité des données dans l'export lui-même. Si vous n'essayez qu'un seul assistant, essayez celui-là.
2. Gemini Pro : solide deuxième. Analyse narrative, honnête sur ses limites dans les premiers rounds, mais a livré un PDF entièrement brandé avec des chiffres cohérents dans le round final. Une vraie alternative à Claude.
3. Google AI Studio : la meilleure profondeur textuelle sur les données, mais ne peut pas livrer de fichiers dans l'interface de chat. Utile si vous voulez copier-coller l'analyse, pas si vous avez besoin d'un PDF.
4. ChatGPT Plus avec Code Interpreter : chiffres corrects dans l'analyse, mais produit des PDF dont les chiffres ne correspondent pas toujours à l'analyse. Utilisable si vous n'avez besoin que du texte.
5. Grok : sortie d'apparence compétente, mais vérifiez les chiffres vous-mêmes. Nous avons vu des valeurs inventées dans nos tests.
6. Copilot : pas adapté à cette tâche pour le moment. Prétend que le fichier est tronqué alors qu'il ne l'est pas, et propose une solution à un problème qui n'existe pas.

Si vous n'avez le temps d'essayer qu'un seul assistant, notre conseil concret est de commencer par Claude sur claude.ai. La combinaison de profondeur analytique, de volonté de questionner la qualité des données et de sortie PDF brandée fiable fait de Claude le leader évident dans nos tests. Gemini Pro est une alternative crédible, surtout depuis sa montée en gamme dans le dernier round. Les autres ont leurs points forts, mais pour cette tâche spécifique (analyse structurée d'un jeu de données moyennement volumineux avec un livrable PDF brandé), l'écart entre Claude et le reste est réel.

Mise en garde importante : ceci est un instantané. Les assistants IA évoluent chaque semaine. Le modèle derrière ChatGPT aujourd'hui peut être un modèle différent dans un mois, avec des points forts différents. Anthropic, OpenAI, Google, xAI et Microsoft poussent tous des mises à jour majeures sur des cycles de quelques semaines à quelques mois. Au moment où vous lisez ceci, le classement peut avoir changé, parfois considérablement. Si la meilleure sortie vous importe, il vaut la peine de retester votre assistant favori tous les quelques mois sur une tâche de référence connue.

Notre classement est aussi spécifique à cette seule tâche : analyse structurée d'un jeu de données moyennement volumineux, bien formaté, avec des instructions explicites. Pour la conversation, la génération de code, l'écriture créative ou la recherche web, l'ordre serait presque certainement différent.

Ce que cela signifie pour la conception de prompts

Quatre itérations ont substantiellement modifié notre prompt. Chaque changement était motivé par un mode d'échec spécifique que nous avions observé :

Premièrement, nous avons rendu le prompt agressif sur le plan des vérifications de capacités. La toute première chose que nous demandons maintenant à l'IA, c'est de vérifier qu'elle a reçu le fichier complet (en cherchant notre marqueur de fin explicite), de confirmer si elle dispose de l'exécution de code, et de confirmer si elle peut à la fois générer et livrer des fichiers PDF. Cela attrape tôt la confabulation à la Copilot et force les modèles comme Google AI Studio à déclarer à l'avance qu'ils ne peuvent pas livrer de fichiers.

Deuxièmement, nous avons rendu le prompt agressif sur le calcul, pas l'estimation. Le prompt initial suggérait poliment que l'IA « pouvait utiliser Python si disponible ». Le prompt actuel dit explicitement : n'estimez ni n'approximez jamais un chiffre si vous pouvez le calculer. Les données de ce fichier sont précises ; votre analyse doit l'être aussi. Nous avons soutenu cela par des formules explicites dans une Annexe de calcul, pour qu'il n'y ait aucune ambiguïté sur la façon de calculer quoi que ce soit.

Troisièmement, nous avons ajouté une règle d'honnêteté : nous préférons une analyse partielle mais honnête à une analyse complète mais inventée. C'est la règle qui, si elle fonctionne, devrait étouffer les inventions à la Grok et transformer les PDF précipités à la ChatGPT en sauts honnêtes.

Quatrièmement, nous avons restructuré le prompt pour que les 39 questions spécifiques soient imbriquées comme sujets dans les 14 sections narratives, plutôt que listées séparément comme Q&R à la fin. C'était la leçon la plus largement applicable : la structure de votre prompt devient la structure de la sortie. Si vous voulez une analyse fluide, vous devez demander une analyse fluide, pas une checklist.

Et cinquièmement, nous avons ajouté une règle single-source-of-truth pour le PDF : chaque chiffre du PDF doit provenir du même dict calculé qui sous-tend l'analyse Markdown, et ne jamais être recalculé. Cela demande essentiellement à l'IA de gérer un état entre deux phases d'une tâche complexe, ce qui est sincèrement difficile pour les modèles actuels, mais cela rend au moins visible quand cela tourne mal.

Rien de tout cela ne nous aurait été visible sans avoir lancé le test : quatre fois, avec le même jeu de données, avec les mêmes six modèles, avec des instructions de plus en plus précises. La première version de notre prompt était, selon toute revue interne raisonnable, un ensemble d'instructions rigoureux et bien pensé. Ce n'est que lorsque nous avons vu six assistants IA différents produire six sorties différentes de qualité très variable, puis ces sorties s'améliorer à chaque itération, que nous avons compris à quel point une grande partie du prompt relevait de l'hypothèse implicite plutôt que de l'instruction explicite.

La leçon plus large, pour quiconque utilise l'IA sur de vraies données

Si vous ne construisez pas une application et que vous déposez juste de temps en temps un CSV dans ChatGPT pour le faire résumer, cet article n'est probablement pas pour vous. Le prompt à 39 sujets, PDF brandé et structure multicouche que nous avons construit pour HelioPeak est surdimensionné pour des analyses ponctuelles. Mais il y a quatre principes issus de notre test qui nous semblent généralisables à tout usage sérieux de l'IA sur de vraies données.

Principe un : dites à l'IA exactement quoi calculer, y compris les constantes. « Quel est l'impact carbone de ma production solaire » est trop ouvert. « Calculez le CO₂ évité total avec un facteur de 0,467 kg par kWh, puis exprimez-le en équivalent km voiture en supposant 120 g CO₂ par km, en équivalent arbres adultes en supposant 21 kg absorbés par arbre par an, et en équivalent ménage-année en supposant 1 635 kg CO₂ par ménage UE et par an » vous donne la même réponse de tout modèle.

Principe deux : forcez l'IA à déclarer ses capacités à l'avance. Si vous ne le faites pas, les modèles essaieront souvent des tâches qu'ils ne peuvent livrer, ou refuseront des tâches qu'ils peuvent gérer. La vérification préalable met les attentes au clair des deux côtés.

Principe trois : intégrez une règle d'honnêteté. Dites directement à l'IA que vous préférez une réponse partiellement honnête à une réponse complètement inventée. Cela n'arrête pas toutes les hallucinations, mais dans nos tests, cela a sensiblement réduit le rythme auquel les modèles inventaient des valeurs pour combler les vides.

Principe quatre : la structure de votre prompt devient la structure de la sortie. Si vous demandez un récit de 13 sections ET une Q&R de 39 questions, vous obtenez les deux, et la Q&R restera maladroitement en bas comme un devoir. Si vous voulez une analyse fluide, intégrez vos questions spécifiques dans les sections narratives comme « sujets à couvrir » plutôt que comme liste séparée. Les questions continuent de guider la rigueur ; elles disparaissent simplement dans la prose là où elles ont leur place.

Aucun de ces principes n'est révolutionnaire. Ils apparaissent dans des articles académiques sur le prompt engineering, dans les guides de prompting d'OpenAI et d'Anthropic eux-mêmes, dans les billets de blog de gens qui font ce métier. Ce que notre expérience a ajouté, c'est la preuve empirique qu'appliquer ces principes, sur une vraie tâche avec de vraies données, modifie sensiblement la qualité de sortie de plusieurs modèles.

Et la suite ?

La fonction « Export pour analyse IA » arrivera dans une future version de HelioPeak, après que le code iOS soit écrit, testé et validé par Apple. Au moment où vous lisez ceci, elle est peut-être déjà en ligne ; consultez la page des notes de version pour l'état actuel.

Quand elle sera disponible, elle produira le même fichier Markdown autoportant que nous avons testé ici. Vous pourrez le coller dans l'assistant IA de votre choix. Nous publierons une entrée FAQ avec nos recommandations actuelles de modèles et une note précisant que ces recommandations peuvent évoluer dans le temps. Nous n'allons pas vous lier à un assistant unique. Nous allons juste vous fournir le fichier d'export de données le plus utile que nous puissions concevoir, et c'est à vous de choisir où l'envoyer.

Nous allons aussi continuer à relancer ce test. Tous les trimestres environ, nous passerons le même export dans la version la plus récente de chaque assistant IA majeur, observerons comment le classement a évolué et mettrons à jour cet article. L'IA évolue trop vite pour qu'un instantané reste utile longtemps. La méthodologie, le jeu de données et le prompt sont stables ; les assistants ne le sont pas. C'est ce qui rend le benchmark intéressant.

Si nous avons une seule conclusion à tirer de quatre itérations sur un seul week-end, c'est celle-ci : les assistants IA sont des outils extraordinairement puissants qui échouent de façons extraordinairement spécifiques. La manière de traiter ces échecs ne consiste pas à changer d'outil ni à abandonner ; elle consiste à affiner les instructions jusqu'à ce que chaque mode d'échec disparaisse. L'Annexe de calcul a résolu la divergence. La vérification de capacités a (en grande partie) résolu la confabulation. La restructuration narrative a résolu le format devoir. La règle single-source-of-truth a commencé à résoudre l'écart PDF. Chaque correctif est petit pris séparément, mais ensemble ils transforment un outil peu fiable en un collaborateur utile.

Si vous construisez quelque chose de similaire et que vous voulez comparer vos notes sur la conception de prompts pour l'analyse de données structurées, vous savez où nous trouver.

Cet article documente les tests réalisés le 23 mai 2026 sur quatre itérations de notre conception de prompt (v0.1 à v0.4). La spécification d'export est désormais figée en v0.4 et prête pour l'implémentation iOS. L'application HelioPeak pour iOS, qui suit les systèmes PVOutput.org, est disponible sur l'App Store.

Cet article a été rédigé en anglais et traduit avec l'aide de l'IA. Lire l'original en anglais.

← Retour au blog