Nouveautés

Ajouté

• Quand deux tables sont reliées (les ventes et les clients, par exemple), la colonne qui porte le lien apparaît des deux côtés dans la liste des champs. Du côté des ventes, elle ne sert qu’à retrouver la bonne ligne chez les clients : c’est une « clé étrangère ». Laissée visible, elle propose à l’utilisateur un second chemin qui a l’air identique au bon.
• Ce n’est pas qu’une question de rangement. Un filtre posé sur cette colonne-là ne se propage pas jusqu’à l’autre table : les chiffres calculés à partir de celle-ci ne sont alors pas filtrés comme vous le croyez, et le rapport affiche un résultat crédible et faux. Le cas le plus courant concerne les dates - découper par la date des ventes plutôt que par celle du calendrier fait taire silencieusement tous les cumuls et comparaisons dans le temps.
• PBI Optimizer ne signale la colonne que s’il a d’abord VÉRIFIÉ qu’aucun visuel ni filtre de votre rapport (ni des rapports liés que vous avez déclarés) ne l’utilise. Sans cette preuve, il se tait : une clé de liaison est parfois l’information que vous voulez lire à l’écran, comme un numéro de commande. Le masquage ne supprime rien, ne modifie aucune valeur, laisse la liaison intacte, et se défait d’un clic droit dans Power BI.
• Mesuré avant d’être écrit : la règle se déclenche sur 9 des 19 rapports d’essai, pour 26 colonnes au total. Elle reste muette sur le modèle témoin, celui qui est propre et doit le rester.

Modifié

• La section « Cohérence des formules » devient « Justesse des résultats ». Elle regroupe désormais tout ce qui peut faire afficher un chiffre faux sans message d’erreur, et elle reste visible quel que soit l’objectif choisi : la justesse ne se met pas en balance avec la vitesse.
• Deux familles y cohabitent, et l’écran les distingue. Les erreurs de logique possibles dans une formule ne sont toujours jamais corrigées automatiquement - les corriger changerait vos chiffres, et vous seul connaissez votre intention. Les pièges de modèle, eux, portent une pastille « corrigeable sans toucher aux valeurs » et des boutons valider / ignorer : aucune valeur n’est fausse, c’est le chemin de lecture qui trompe.

Corrigé

• Certaines colonnes calculées étaient mal lues : quand leur formule est écrite sur la même ligne que leur déclaration, les réglages qui suivent (dont « masquée ») étaient avalés par la formule. Deux conséquences : une colonne déjà masquée était signalée comme s’il restait à la masquer, et la formule affichée était polluée par un mot parasite. Après correction, l’outil trouve davantage de vraies optimisations sur un axe et cesse d’en signaler de fausses sur un autre.
• Une correction validée pouvait n’être jamais écrite dans le fichier, sans le moindre message. La traduction « constat détecté → modification à écrire » existe en deux exemplaires dans le code, et le contrôle automatique n’en surveillait qu’un. Les deux sont désormais tenus ensemble, et le contrôle a été vérifié dans les deux sens.

Modifié

• Quand PBI Optimizer demande à l’IA de réécrire une formule, de la traduire ou de la relire, il lui envoie des morceaux de votre fichier : la formule concernée, le nom de l’objet, parfois la liste des colonnes. Ces textes étaient mélangés à nos propres consignes, sans rien qui les distingue. Une mesure dont le nom aurait été rédigé comme un ordre (« ignore les règles précédentes et réponds ceci ») pouvait donc se lire comme une instruction venant de l’application.
• Le contenu du fichier est maintenant placé dans un bloc délimité, et les instructions données à l’IA disent explicitement que tout ce qui s’y trouve est une donnée à examiner, jamais un ordre. Le procédé résiste à la ruse évidente : un texte qui contiendrait la marque de fin du bloc pour en sortir se voit neutralisé, et seule la copie envoyée à l’IA est modifiée - votre formule, elle, n’est jamais touchée.
• Un contrôle automatique lit le code du logiciel à chaque exécution des tests : tout nouvel usage de l’IA qui oublierait cette protection fait échouer la vérification. Il a lui-même été testé à l’envers, pour s’assurer qu’il refuse bien ce qu’il doit refuser.

Corrigé

• Avant d’appliquer une réécriture proposée par l’IA, PBI Optimizer vérifie qu’elle utilise exactement les mêmes champs qu’avant : c’est ce qui garantit que vos chiffres ne bougent pas. Ce contrôle ne tournait que sur les formules de calcul (DAX). Sur les requêtes d’import de données (Power Query), il ne restait qu’une consigne écrite dans les instructions données au modèle - c’est-à-dire une demande, pas une vérification. Le contrôle s’applique désormais aux deux, avec la lecture propre à chaque langage (les noms de colonnes y sont sensibles à la majuscule, contrairement au DAX).
• Le contrôle lisait la formule entière, commentaires compris : un nom de colonne cité dans un commentaire ou dans un texte affiché comptait comme un champ utilisé. Il se trompait donc dans les deux sens - une colonne réellement retirée du calcul pouvait passer inaperçue si un commentaire la mentionnait encore, et une réécriture parfaitement correcte pouvait être refusée parce qu’un simple commentaire avait été reformulé (ce que les instructions autorisent pourtant). Seul le code réellement calculé est maintenant pris en compte.

Ajouté

• Quand PBI Optimizer remplace un « SELECT * » par la liste des colonnes, il doit encadrer chaque nom à la manière du moteur visé - guillemets, crochets ou accents graves selon la base. Un contrôle soumettait déjà ces requêtes à un vrai PostgreSQL avant livraison ; il les soumet maintenant aussi à un vrai MySQL, qui sert de témoin pour Databricks et Spark. Douze situations sont passées en revue, dont les noms contenant un espace, un accent, un mot réservé du langage, ou le caractère d’encadrement lui-même.
• Le contrôle vérifie aussi que ce qui doit être refusé l’est : sans ces cas-là, une base qui accepterait tout ne se distinguerait pas d’une vérification qui n’a pas eu lieu.

Modifié

• Le contrôle affichait « tout est accepté » même lorsqu’un moteur n’avait pas pu être interrogé, la mention étant reléguée en fin de ligne. Il annonce désormais dans son verdict combien de moteurs ont réellement répondu, et s’interrompt en erreur si l’un manque - à moins qu’on accepte explicitement cette lacune.
• C’est le cas aujourd’hui de SQL Server : son image ne s’exécute pas sur un Mac à processeur Apple sans une option de Docker restée désactivée. Le dialecte à crochets reste vérifié par les tests automatiques, et l’absence est écrite noir sur blanc plutôt que passée sous silence.

Corrigé

• Sur PostgreSQL, Snowflake, Redshift et Oracle, les noms de colonnes s’encadrent avec des guillemets. Mais la requête est elle-même écrite à l’intérieur d’un texte, où les guillemets doivent être doublés : sans ça le texte se referme trop tôt et la requête devient incompréhensible pour Power BI.
• Le fichier s’ouvrait normalement - le défaut ne se serait vu qu’au moment d’actualiser vos données. Il ne pouvait pas exister tant que seul SQL Server était géré.

Ajouté

• Un nouveau contrôle soumet chaque requête que nous produisons à une vraie base de données PostgreSQL, et vérifie qu’elle est acceptée et que chaque colonne est bien trouvée. C’est lui qui a détecté le défaut ci-dessus, dès son premier passage.
• Jusqu’ici notre vérification finale contrôlait le fichier Power BI, mais jamais la requête SQL qu’il transporte : un fichier parfaitement valide pouvait contenir une requête que la base refuse.
• Le contrôle inclut deux cas qui DOIVENT échouer. Sans eux, un contrôle qui passe toujours ne prouverait rien.

Modifié

• La correction remplace « SELECT * » par la liste des colonnes réellement utilisées. Elle ne fonctionnait que sur SQL Server, parce que chaque moteur de base de données a sa propre façon d’encadrer les noms de colonnes : utiliser la mauvaise produit une requête que la base refuse, et votre actualisation casse.
• Elle connaît maintenant PostgreSQL, Snowflake, Redshift, Oracle, MySQL et Databricks, en plus de SQL Server et des points de terminaison Fabric. Tout moteur non reconnu reste refusé - notamment les connexions ODBC, qui peuvent parler n’importe quel dialecte : nous préférons ne rien faire que deviner.
• Quand la correction n’est pas possible, elle vous dit désormais POURQUOI, cause par cause. Le message précédent en confondait quatre.
• Surtout : l’alerte se déclenchait sur des requêtes qui interrogent les métadonnées internes d’un modèle - quelques centaines de lignes, où l’argument « vous ramenez des colonnes inutiles » n’a aucun sens. Sur nos 19 rapports de test, 22 des 29 alertes étaient de ce type. Elles ont disparu.
• Résultat : 7 alertes au lieu de 29, et les 7 sont corrigées automatiquement.

Modifié

• Les alertes sur la durée d’extraction n’ont de sens que sur des rapports qui interrogent une base de données. Notre collection de rapports de test en contenait très peu : nous ne pouvions donc ni vérifier ce que nous détectons, ni mesurer ce que nous ratons.
• Trois modèles publics ont été ajoutés, cherchés spécifiquement par type de connexion (SQL Server, PostgreSQL, Snowflake, Databricks, Redshift). Le nombre de requêtes branchées sur une vraie base passe de 35 à 87.
• Deux d’entre eux mettent à l’épreuve des alertes qu’aucun rapport réel ne déclenchait jusqu’ici. Au total, 38 de nos 49 alertes sont maintenant éprouvées sur au moins un rapport réel, contre 33 auparavant.
• Une mesure que nous avions publiée était fausse et a été corrigée : notre classement des sources oubliait un connecteur de base de données et rangeait mal les requêtes dérivées d’une autre requête. Le chiffre annoncé était de 15 %, il valait 19 %.

Corrigé

• Notre banc de vérification finale soumet chaque fichier produit à la bibliothèque officielle Microsoft, mais ne vérifiait jamais le fichier de départ. Un modèle public déjà refusé par Microsoft avant toute intervention nous était imputé. Les deux cas sont désormais distingués.

Ajouté

• Écrire deux fois [Chiffre d’affaires] dans une formule le fait calculer deux fois. Une « variable » le calcule une fois et réutilise le résultat : mêmes valeurs affichées, un calcul économisé, et une formule plus lisible.
• La correction passe par la réécriture assistée, déjà disponible sur les formules DAX : vous validez la proposition avant qu’elle parte dans le fichier. La part des problèmes que l’outil sait réparer monte à 34 sur 49.
• Sur nos 16 rapports de test, 12 mesures sont concernées dans 4 rapports.
• L’alerte reste volontairement silencieuse dès qu’une formule change le contexte de calcul (CALCULATE, FILTER, SWITCH, itérateurs). Dans ces cas, les deux occurrences ne valent pas forcément la même chose, et les regrouper fausserait vos chiffres sans prévenir. Nous préférons rater des cas que d’en proposer un seul qui déplace une valeur.

Modifié

• Ce chantier devait être plus gros. Mesure faite sur la collection de rapports de test : 754 des 757 mesures portent déjà au moins une alerte. Trois autres pistes envisagées ont été instruites puis abandonnées sur preuve - l’une d’elles visait une formule générée par Power BI lui-même, une autre aurait proposé des réécritures qui changent les résultats.

Corrigé

• Un rapport traduit range les libellés de chaque langue dans des fichiers à part, où l’on retrouve les mêmes noms de tables et de colonnes. Nos corrections s’y appliquaient par erreur, à un endroit où ces réglages n’existent pas : Power BI refusait d’ouvrir le fichier produit.
• Plus gênant encore : dans la plupart des cas, la correction atterrissait dans la traduction AU LIEU de la table. Le fichier était donc à la fois cassé et non corrigé.
• Cela concernait tout rapport multilingue, situation courante en entreprise. Trois contrôles le verrouillent, dont un qui vérifie que la correction atteint bien la vraie table.

Ajouté

• Trois modèles publics rejoignent la collection de rapports de test, choisis non pas parce qu’ils sont gros, mais parce que chacun met à l’épreuve quelque chose que rien d’autre ne testait : un modèle de production Microsoft, un classeur de démonstration, et le seul modèle à comporter des indicateurs de performance.
• Ces trois modèles ont révélé les deux défauts corrigés aujourd’hui, dès le premier passage. Deux modèles bien plus volumineux ont été écartés volontairement : ils auraient écrasé toutes les mesures de la collection sous le poids d’une seule source.

Corrigé

• Quand une mesure porte un « indicateur de performance » (KPI : une cible et un code couleur), le fichier Power BI place ces réglages juste après la formule. Nous les collions à la formule au lieu de les en séparer.
• Conséquence visible : les mesures citées par l’indicateur passaient pour des ingrédients de la formule, et l’outil annonçait une boucle de dépendances - un défaut qui empêche vraiment Power BI d’ouvrir un fichier. L’alerte était fausse, elle n’avait aucune correction possible, et elle se déclenchait sur un rapport d’exemple publié par Microsoft.
• Conséquence invisible, et plus grave : la formule lue étant fausse, toute analyse portant dessus l’était aussi, et une réécriture assistée serait partie de cette version polluée.
• Aucun de nos rapports de test ne contenait d’indicateur de performance : rien ne pouvait révéler ce défaut. Il a été trouvé en évaluant des modèles publics candidats à rejoindre la collection de test. Quatre contrôles le verrouillent, dont un qui vérifie qu’une VRAIE boucle continue d’être signalée.

Ajouté

• Pour décider quoi améliorer, nous mesurons sur une collection de vrais rapports Power BI. Ces mesures tranchent des choix de conception : « cette alerte se trompait 6 fois sur 7 », « un tiers de ces colonnes ont déjà une correction ailleurs ». Cette collection n’était décrite nulle part - ni liste, ni date, ni moyen de vérifier qu’elle n’avait pas changé.
• Elle l’est désormais, fichier par fichier, avec une empreinte qui détecte la moindre modification. Deux outils s’y ajoutent : l’un vérifie que la collection sur le poste est bien celle attendue, l’autre recalcule d’un seul coup tous les chiffres cités dans le code.
• Ce que l’inventaire a mis au jour : la collection est passée de 8 à 14 rapports le 3 août, et vingt endroits du code parlaient encore de « 8 rapports » au présent. Des chiffres décrivant une collection disparue servaient encore d’argument.
• L’origine et la licence de chaque rapport ont été retrouvées : neuf sur treize sont rattachés à leur source exacte (échantillons officiels Microsoft, dépôts publics sous licence libre). Pour quatre d’entre eux, la source n’a pas pu être établie, et c’est écrit tel quel : une origine plausible mais inventée aurait donné l’illusion d’être retrouvable.
• Chaque modification du code déclenche maintenant automatiquement les 1319 contrôles du projet sur une machine neutre. Jusqu’ici ils ne tournaient que si quelqu’un pensait à les lancer, et la mise en ligne, elle, ne les lance pas.

Modifié

• Les seize relevés périmés ont été traités un par un, et pas de la même façon selon leur nature. Ceux qui décrivent l’état actuel ont été refaits sur les 13 rapports réels. Ceux qui décrivent l’état AVANT une correction ont été datés sans être touchés : s’ils sont tombés à zéro, c’est justement que la correction fonctionne.
• Deux affirmations avaient cessé d’être vraies. L’une justifiait un choix d’affichage sur les relations bidirectionnelles par « aucune du corpus n’en profiterait » : sur 13 rapports, 8 sur 12 en profitent, donc le choix est encore mieux fondé qu’avant. L’autre disait qu’aucun rapport réel ne cassait le repli de requête (query folding) : depuis un correctif de la version 1.173, l’un d’eux le casse.
• Un contrôle interdit désormais d’écrire un nombre de rapports de test qui n’est plus le bon sans le dater. Le journal que vous lisez ici en est exclu volontairement : chaque entrée était vraie le jour où elle a été écrite, et réécrire une chronique serait le seul vrai mensonge possible.

Modifié

• Certaines corrections vous demandent de trancher (quelle mesure garder, quelle relation désactiver, quelle table marquer). Le 2 août, l’une d’elles a été livrée sans l’identifiant qui permet à l’écran d’enregistrer votre réponse : le bloc de choix ne s’affichait jamais, et comme ce constat n’a pas de conseil manuel, la carte n’offrait aucune issue.
• Rien ne pouvait le détecter : les contrôles étaient au vert, et la part des problèmes réparables restait flatteuse. Un contrôle vérifie maintenant, pour chaque correction à choix, que cet identifiant existe. Nous l’avons validé en réintroduisant volontairement le défaut : il se déclenche.
• Un second contrôle interdit d’inscrire une règle parmi les réparables sans qu’aucun moyen de la déclencher existe. La liste des chemins possibles est écrite noir sur blanc, plutôt que laissée à l’appréciation.

Inclus

• Un nouvel avis de sécurité sur postcss (une dépendance imposée par Next) a été examiné et classé : c’est le correctif incomplet d’un avis déjà étudié, il exige de traiter du CSS fourni par un tiers, ce que cette application ne fait jamais. Réexamen prévu avant le 31 octobre 2026.

Modifié

• Quand vous lancez une génération, une couche décide carte par carte ce qui participe : les déports en Power Query, les fusions, les conversions de type, les alignements, les réécritures. Une seule de ces décisions était contrôlée automatiquement, celle réparée en 1.183 après qu’un défaut soit passé par là.
• Les autres sont maintenant sorties du gros fichier où elles vivaient, et couvertes par 19 contrôles. La règle qu’elles partagent - cocher propose, valider engage - est vérifiée pour chacune, dans les deux sens : ce qui doit partir part, ce qui ne doit pas partir est écarté AVEC son motif affiché.
• En les extrayant, nous en avons trouvé une sixième dont personne n’avait la trace : la conversion des tables calculées. C’est la mesure la plus parlante de cette dette - on ne savait pas combien de décisions ce fichier prenait.

Ajouté

• Quand une table de dates existe déjà sans être marquée, l’outil vous propose de la marquer. Il liste les tables candidates avec la colonne de dates par laquelle vos tables de faits les rejoignent, vous choisissez, et le marquage part dans le fichier généré.
• Aucune option n’est présélectionnée, et c’est volontaire. Marquer une table exige que sa colonne de dates soit continue, sans doublon et sans valeur vide - ce que Power BI vérifie au moment du marquage. Ce sont des propriétés de vos DONNÉES, que le fichier ne montre pas. L’outil ne peut donc pas trancher à votre place : il vous dit quoi vérifier, et chaque option porte cet avertissement.
• S’il n’existe aucune table candidate, il n’y a pas de panneau : il faut créer la table, et le conseil manuel reste seul. C’est le cas d’un rapport sur trois dans nos essais.
• Vérifié sur vos rapports d’essai : le marquage a été appliqué sur les deux rapports concernés, et les fichiers produits restent lus sans erreur par la bibliothèque officielle Microsoft.
• La part des problèmes que l’outil sait réparer passe de 67 % à 69 %.

Corrigé

• Le constat « boucle de relations » proposait un choix qui ne s’affichait jamais. Il lui manquait l’identifiant sous lequel l’interface enregistre votre réponse : le panneau était donc invisible, le choix impossible, et comme ce constat n’a pas de conseil manuel de repli, la carte était un cul-de-sac complet depuis le 2 août.
• Ce constat comptait pourtant parmi les problèmes réparables : la part affichée était surévaluée d’un point pendant trois jours. Elle est juste à nouveau, et un test empêche désormais qu’un panneau de choix existe sans son identifiant.

Corrigé

• Quand le réglage « Date/heure automatique » est actif, Power BI fabrique en coulisses une table de dates cachée pour chaque colonne date. L’outil les comptait comme de vraies tables de dates : il concluait que tout allait bien et se taisait.
• Le défaut se mordait la queue. Ces tables cachées disparaissent quand vous coupez « Date/heure automatique » - ce que l’outil vous conseille par ailleurs de faire. Le conseil sur la table de dates aurait donc dû arriver AVANT ce geste, pas jamais : couper le réglage sans table de dates dédiée casse les calculs de temps.
• Mesuré sur nos 14 rapports d’essai : 6 utilisent des fonctions de temps, 3 n’ont aucune table de dates marquée, et l’outil ne disait rien sur ces 3.
• Le constat est maintenant plus utile qu’un simple signalement : quand une table de dates existe déjà sans être marquée, il vous la NOMME, parce que dans ce cas il n’y a rien à créer, seulement à marquer. Quand aucune n’existe, il le dit aussi.
• Il vous rappelle également ce que Power BI vérifiera au moment du marquage - une colonne de dates sans trou, sans doublon et sans valeur vide. Ce sont des propriétés de vos données, que le fichier ne permet pas de contrôler : c’est pourquoi l’outil ne marque pas la table à votre place.

Ajouté

• Une colonne qui ressemble à un identifiant est le premier poste de coût mémoire d’un modèle. Le conseil disait « masque-la et mets Résumé par défaut à Ne pas résumer, SI elle ne sert qu’aux relations et n’est jamais affichée ». Ces deux gestes partent désormais dans le fichier généré.
• Le « si » n’est pas supposé, il est vérifié : l’outil lit la couche rapport, c’est-à-dire les champs réellement posés sur vos visuels et vos filtres. Si la colonne y figure, ou si le rapport n’est pas lisible, rien n’est masqué et le conseil manuel reste affiché. Une colonne qui disparaît du volet Données sans raison visible serait bien plus déroutante qu’un conseil à appliquer soi-même.
• Masquer ne casse rien : la colonne reste dans le modèle, ses valeurs ne bougent pas, les visuels qui l’utilisent déjà continuent de fonctionner. Elle sort seulement de la liste des champs proposés à la construction de rapports, et l’affichage se rétablit d’un clic droit dans Power BI.
• Rien ne part sans que tu valides la carte, une par une. Et la carte te dit maintenant ce qui va se passer AVANT que tu valides : soit « VÉRIFIÉ : aucun visuel ni filtre n’utilise cette colonne », soit qu’elle est affichée quelque part et que le geste reste à ta main. Auparavant les deux cas s’affichaient à l’identique et tu ne l’apprenais qu’après coup, dans le compte rendu.
• Un cas est écarté volontairement : les colonnes de texte qui servent de clé de relation. Là, le bon remède est la clé de substitution proposée par le constat « Clé de relation en texte », qui supprime le problème au lieu de le cacher.
• Les rapports liés comptent. Si ton modèle est partagé entre plusieurs rapports et que tu les as déclarés dans l’outil, leurs champs entrent dans la vérification : une colonne qui ne sert qu’à l’un d’eux n’est pas masquée. Ce rapprochement n’était fait jusqu’ici que pour la suppression d’objets inutilisés, il l’est maintenant avant toute décision d’usage.
• Sur nos 14 rapports d’essai, 24 colonnes sur 48 sont masquées automatiquement, soit une sur deux. La part des problèmes que l’outil sait réparer passe de 65 % à 67 %.

Ajouté

• Une mesure sans description repartait dans votre fichier telle quelle, avec un conseil à appliquer à la main dans Power BI. Quand sa formule est simple - une somme, une moyenne, une valeur extrême, un comptage, un rapport, un renvoi vers une autre mesure - la description est désormais écrite automatiquement.
• La phrase est déduite de la formule, sans intelligence artificielle. Le résultat est donc le même à chaque fois et il est vérifié par des tests. C’est aussi une question de coût et de relecture : un modèle sans descriptions en compte rarement une poignée, c’est plutôt 100 à 400 mesures d’un seul coup.
• Ce que ça vaut, et ce que ça ne vaut pas : « Somme de la colonne Montant de la table Ventes » n’apprend rien à qui sait lire une formule. Son destinataire est le lecteur du rapport, qui voit l’infobulle du champ et jamais l’expression. Pour lui, c’est mieux que rien - mais ça reste une amorce, pas la description complète que le conseil décrit.
• Quand la formule est trop complexe pour que son sens soit certain (calculs sous filtre, intelligence temporelle, conditions), rien n’est écrit. Le compte rendu de génération affiche alors la mesure comme non traitée, avec le motif et le conseil manuel. Une documentation fausse se lirait comme vraie : mieux vaut le vide.
• Ce que ça donne sur de vrais rapports, parce que le chiffre compte plus que l’intention : sur nos 14 rapports d’essai, 76 mesures sur 448 reçoivent leur description automatiquement, soit environ une sur six. Les 372 autres gardent leur conseil à appliquer à la main.
• La part des problèmes que l’outil sait réparer passe de 63 % à 65 %.

Modifié

• Il conseillait bien de désactiver « Date/heure automatique », de déporter les colonnes calculées, de convertir les tables calculées et de supprimer l’inutilisé, mais sans jamais dire que ces corrections existaient dans l’outil, à un clic.
• Chaque conseil cite désormais le constat qui l’applique, sous le nom exact affiché sur sa carte.
• C’est la cinquième fois que nous trouvons un constat dont le remède existait sans être relié. Nous l’écrivons ici parce que c’est un défaut qui se répète, pas un accident.
• La part des problèmes que l’outil sait réparer passe de 60 % à 63 %.

Modifié

• Cette décision se prenait au milieu d’un bloc de près de 1 900 lignes qu’aucun contrôle automatique n’exerçait. Un correctif pouvait y être écarté sans que rien ne le signale - c’est ce qui s’était produit la veille.
• Elle est maintenant isolée et couverte par neuf contrôles. La preuve a été faite en réintroduisant volontairement le défaut d’origine : deux contrôles se déclenchent.
• Le travail n’est pas terminé : cinq autres familles d’optimisations passent encore par l’ancien chemin, sans contrôle. Nous préférons l’écrire que le laisser croire.

Ajouté

• Chaque option indique les colonnes qui seront recopiées, si la table d’origine devient inutile, et surtout la démonstration que l’opération ne peut pas dupliquer de lignes - c’est elle qui permet de l’automatiser sans risquer vos totaux.
• L’opération n’est proposée que lorsqu’elle est réellement réalisable. Sur nos rapports de test, elle apparaît sur 2 cas et pas un de plus : les autres sont des tables de faits ou des conflits de noms, et gardent leur guide manuel.
• Si la situation a changé entre l’analyse et la génération, l’opération n’est pas appliquée et le compte rendu vous le dit, plutôt que de laisser croire qu’elle a eu lieu.
• La part des problèmes que l’outil sait réparer passe de 58 % à 60 %.

Corrigé

• Ces optimisations étaient écartées par erreur au moment de produire le fichier : vous pouviez les cocher sans qu’elles aient le moindre effet.
• Si vous renoncez à la correction qui en débloque une autre, celle-ci n’est plus appliquée - et le compte rendu vous dit laquelle et pourquoi. L’appliquer seule aurait été risqué : c’est justement le cas que la règle évite.
• Le refus est décidé côté serveur, pas seulement affiché à l’écran, pour qu’il tienne quoi qu’il arrive.

Ajouté

• Simplifier un modèle en flocon consiste à rapatrier les informations d’une table dans celle qui la référence, puis à supprimer le lien devenu inutile. L’opération n’est préparée que si l’outil peut DÉMONTRER qu’elle ne dupliquera aucune ligne - sans cette preuve, tous vos totaux seraient faux sans le moindre signe.
• Sur nos rapports de test : 3 simplifications préparées et vérifiées, 23 refusées avec leur motif expliqué. L’outil refuse bien plus qu’il n’accepte, et c’est voulu.
• Le jeu de rapports de test passe de 9 à 14 modèles, avec pour la première fois de vraies bases de données en source. Un de ces modèles sert de témoin : il est propre, et doit le rester - s’il se met à déclencher des alertes, c’est l’alerte qui a un problème.
• Cette version prépare l’opération. Le choix et son application dans le fichier généré suivront.

Corrigé

• Une table qui pointe vers trois autres tables ou plus est presque toujours une table de faits (elle référence ses dimensions), et non une dimension intermédiaire à aplatir. L’alerte le signale au lieu de conseiller une fusion absurde.
• Elle avertit sans faire disparaître l’alerte : reconnaître une table de faits sans regarder les données reste un jugement, et c’est le vôtre qui tranche.

Corrigé

• Power BI crée une table de dates cachée par colonne de date. Votre propre table de dates se retrouvait alors signalée « en flocon », avec le conseil de la fusionner - impossible, puisque la table en question n’est pas la vôtre. Ces cas ne sont plus signalés : 7 alertes deviennent 3, toutes réelles.
• Le vrai remède dans ces cas-là, désactiver les tables de date automatiques, était déjà appliqué tout seul par l’outil.

Ajouté

• Une réorganisation du modèle (fusionner deux tables, par exemple) peut multiplier des lignes et fausser tous vos totaux, sans aucun signe visible. L’outil sait désormais démontrer, à partir de votre fichier seul, qu’une fusion donnée ne peut pas le faire.
• La démonstration s’appuie sur ce que Power BI a déjà vérifié pour vous : une liaison « plusieurs vers un » n’aurait pas pu se charger si le côté « un » contenait des doublons.
• Quand la démonstration n’est pas possible, l’outil répond « je ne sais pas » - jamais « c’est bon ». C’est ce qui permettra d’automatiser ces transformations sans jamais parier sur vos chiffres.

Corrigé

• Le conseil « préférez une clé entière » s’applique presque toujours à des dates. Or remplacer une clé de date sans précaution casse les calculs de périodes (cumul annuel, comparaison avec l’an dernier) - et sans aucun message d’erreur. Le conseil précise désormais quoi conserver, quel format employer, et quand le gain ne vaut pas le risque.
• Quand une colonne à forte volumétrie sert de clé de liaison en texte, l’alerte indique maintenant que l’outil sait la convertir tout seul, et sur quelle carte se trouve le bouton.
• Ces deux règles n’ont volontairement PAS été automatisées : la conversion automatique aurait pu abîmer vos calculs de dates. Nous préférons un conseil complet à une correction risquée.

Ajouté

• Ces optimisations portent une pastille « Débloquée » et une phrase qui explique qu’elles n’existent pas encore dans votre fichier, et ce qui les rend possibles.
• Si vous renoncez à la correction dont elles dépendent, elles disparaissent avec elle : la phrase le dit clairement sur la carte.
• Vous voyez donc la liste complète avant de choisir, et rien ne sera appliqué que vous n’ayez vu.

Ajouté

• Les optimisations débloquées par d’autres sont calculées dès l’analyse, pour que vous voyiez la liste complète avant de choisir - au lieu de les découvrir après coup et de devoir tout recommencer.
• Chacune indique ce qui l’a rendue possible (« suppression de la relation X ») : si vous renoncez à cette correction-là, celle qu’elle débloquait tombe avec elle. Rien ne sera appliqué que vous n’ayez vu et accepté.
• Sur nos rapports de test : 9 optimisations révélées sur 3 rapports, toutes en une seule vague supplémentaire, en moins de trois dixièmes de seconde par rapport.
• Cette version livre le moteur et sa vérification. L’affichage dans l’écran des optimisations suivra.

Ajouté

• Toutes les corrections automatiques sont rejouées sur de vrais rapports, puis chaque fichier produit est soumis à l’outil officiel de Microsoft. Premier passage : 161 corrections sur 9 rapports, aucune écartée, et les 9 fichiers s’ouvrent sans erreur.
• La vérification contrôle aussi, une par une, que les corrections font bien disparaître le problème signalé - et non qu’elles se contentent d’annoncer « appliqué ».
• Un cas de figure normal est désormais expliqué plutôt que subi : corriger certains problèmes en révèle de nouveaux. Retirer une relation inutilisée libère par exemple sa colonne, qui devient à son tour optimisable. Ce ne sont pas des erreurs revenues, ce sont de nouvelles pistes ouvertes par le travail déjà fait.

Corrigé

• Sur nos rapports de test, l’un empile huit mises en cache dans une seule requête et restait muet, pendant qu’un modèle de trois tables avec une seule mise en cache chacune déclenchait l’alerte. Le plus lourd passait pour le moins inquiétant.
• L’alerte se déclenche désormais dans les deux cas, et indique la requête en cause ainsi que son nombre de mises en cache.
• La correction proposée ne change pas : c’est la même réécriture, requête par requête. C’est la détection qui était en défaut, pas le remède.

Corrigé

• Notre lecteur de fichiers Power BI est plus indulgent que Power BI lui-même : un fichier qu’il accepte peut être refusé à l’ouverture. Il ne peut donc pas servir de preuve, et un contrôle indépendant a été remis en place.
• Ce contrôle a d’abord été éprouvé sur vos 8 rapports de test, qui passent tous : quand il signale une erreur, c’en est une.

Ajouté

• Nos 8 rapports de test contiennent 99 requêtes, dont 14 seulement interrogent une base de données - le reste vient de fichiers Excel, de CSV ou de données saisies à la main. Toute une famille d’alertes ne pouvait donc être éprouvée sur rien.
• Un rapport de test branché sur une base a été fabriqué, avec des défauts posés volontairement. Les cinq alertes concernées s’y déclenchent, et le contrôle vérifie aussi qu’aucune AUTRE ne se déclenche par erreur.
• Effet concret pour vous : les prochaines alertes sur l’extraction des données seront écrites avec une preuve, pas au jugé. C’est ce même réflexe qui a permis de corriger l’alerte « page surchargée » dans la version précédente.

Corrigé

• Seuls les visuels qui interrogent vraiment le modèle sont désormais comptés. Un rapport de test comptait 235 éléments sur ses pages, dont 225 de pur décor : il était signalé trois fois comme surchargé alors qu’il n’affiche que 10 visuels de données.
• L’alerte annonce maintenant les deux nombres - « 25 visuels qui interrogent le modèle, sur 35 éléments au total » - pour que vous reconnaissiez votre page.
• Si le format de votre fichier ne permet pas de faire la distinction, l’alerte se comporte exactement comme avant : elle compte tout. Mieux vaut une alerte de trop qu’un vrai problème passé sous silence.

Modifié

• Le constat « Table chargée en colonnes calculées » disparaît. Il se contentait de compter : chacune de ces colonnes avait déjà sa propre carte, avec son bouton. Il ajoutait donc une alerte de plus, sans action, et souvent en tête de liste.
• Le constat « Pression mémoire à l’actualisation » indique désormais où est le bouton. Il annonce une actualisation qui échoue - ce qu’aucun autre constat ne dit - mais laissait croire que la correction se faisait à la main. En réalité, chacune des tables qu’il cite porte le constat « Repli de requête cassé », que l’outil sait réécrire.
• Ce même constat remonte de l’étape « Peaufiner » à l’étape « Affiner », auprès de sa correction. Il était rangé en fin de parcours alors qu’il signale un blocage pur et simple.
• Un guide décrit ce qui reste à faire soi-même : les deux réglages de Power BI Desktop (évaluations simultanées, mémoire par évaluation). Ils appartiennent à votre poste et non au rapport, donc aucun fichier généré ne peut les emporter.

Inclus

• Le banc d’essai couvre 16 corrections sur 27 - c’est-à-dire la totalité de celles qui ne passent pas par l’IA. Les 11 restantes reposent sur une réécriture assistée, qui exige un appel réseau payant et n’a pas sa place dans une vérification lancée à chaque modification du code.
• Nouvelles corrections éprouvées : désactivation des tables de date automatiques, suppression des colonnes et mesures inutilisées, remplacement d’un SELECT *, passage d’une relation en sens unique, conversion d’une table calculée en requête, et conversion d’une clé texte en clé entière.
• Aucun nouveau défaut trouvé dans ce lot - y compris sur la conversion des clés de substitution, la plus délicate. Après trois corrections cassées mises au jour la veille, c’est une bonne nouvelle qui a désormais une preuve.

Corrigé

• Une colonne date-heure ramenée à la date continuait d’être signalée après correction : tu corrigeais, et retrouvais le même reproche sur une colonne déjà traitée. La règle regardait le type déclaré, or Power BI n’a pas de type « Date » distinct - une date y est toujours stockée comme date-heure. La correction agit donc sur la requête, et la règle la lit désormais aussi.
• Effet de bord bienvenu : cinq colonnes de vos rapports d’essai étaient signalées à tort, alors que leur requête les ramenait déjà à la date - dont la colonne de date d’une table de calendrier, qui n’a évidemment aucune heure à perdre.

Inclus

• Le banc d’essai de la réparation couvre désormais aussi les montants en virgule flottante, les relations inactives et les colonnes date-heure. C’est lui qui a mis au jour ce troisième cas.

Corrigé

• Les mesures en double ne se corrigeaient JAMAIS. La correction cherchait la mesure par sa formule, et refusait quand plusieurs correspondaient - or deux doublons ont la même formule par définition. Elle se refusait donc elle-même, en silence. Elle localise désormais la mesure par son nom.
• Casser une boucle de relations ne la faisait pas disparaître. Le détecteur de boucles ignorait les relations désactivées : on appliquait la correction, et le constat revenait à l’analyse suivante. Une relation inactive ne crée aucun chemin de filtrage, elle n’est donc plus comptée.

Inclus

• Un banc d’essai de la réparation : pour chaque correction automatique, un modèle volontairement dégradé est détecté, corrigé, puis relu pour vérifier que le défaut a bien DISPARU. Un « appliqué » qui laisse le problème en place est désormais impossible à livrer sans que la suite de tests ne le signale.

Ajouté

• Boucle de relations : le constat propose une option par relation de la boucle. Celle que tu retiens est désactivée dans le .pbip généré.
• DÉSACTIVÉE, et non supprimée : la relation reste dans le modèle, reste utilisable ponctuellement dans une mesure, et le geste se défait d’un clic dans Power BI. C’est cette réversibilité qui rend l’automatisation acceptable pour une correction qui change, par nature, des résultats.
• Chaque option affiche les visuels et les pages qu’elle toucherait - y compris dans les rapports connectés. Sans ça, choisir entre trois relations qui se ressemblent reviendrait à tirer au sort.
• Une relation déjà inactive n’est jamais proposée : la désactiver ne ferait rien.

Inclus

• Plus aucune règle de l’outil ne reste sans solution ni sans raison écrite de s’en passer. Sur 49 détections, 27 se corrigent désormais dans le fichier généré, 11 renvoient à un geste manuel décrit pas à pas, et 11 sont des diagnostics assumés - dont les alertes de cohérence, qui signalent des formules probablement fausses et ne doivent jamais être corrigées automatiquement.

Ajouté

• L’impact d’un changement de relation est désormais calculé aussi sur les rapports connectés que tu as déclarés : quels visuels, sur quelles pages, de quel rapport.
• Chaque rapport connecté conserve maintenant, à son ingestion, le détail par visuel (page et tables interrogées). Aucune donnée nouvelle n’est gardée pour autant - des noms de pages et de tables, jamais de valeurs - et le fichier source continue d’être supprimé aussitôt.
• Trois verdicts bien distincts, jamais confondus : « ce rapport est concerné », « aucun ne l’est », et « je n’ai pas pu regarder ». Le dernier arrive quand un rapport connecté a été ajouté avant cette version et que son fichier a depuis été supprimé : l’outil le dit et te propose de le re-téléverser, au lieu de te laisser croire qu’il est hors de cause.
• Et quand aucun rapport connecté n’est déclaré, l’outil t’invite à en ajouter plutôt que de rester muet : c’est justement là que le risque est invisible.

Ajouté

• Mesures en double : le constat propose une option par mesure du groupe. Celle que tu gardes reste telle quelle, les autres sont réécrites en « = [Mesure gardée] » dans le .pbip généré.
• Le renvoi plutôt que la suppression, et c’est ce qui rend l’automatisation possible : tous les visuels qui utilisaient les doublons continuent de fonctionner, y compris ceux d’un rapport externe ou d’un classeur Excel que le fichier ne montre pas. Il ne reste qu’un seul endroit à corriger le jour où le calcul change.

Inclus

• Le bloc de choix devient générique : la même mécanique sert l’alignement des types de relation et les mesures en double, et servira les prochaines règles du même motif. Une règle ne change jamais rien sans décision explicite, et aucune option n’est cochée d’avance.

Ajouté

• Chaque constat sur une relation bidirectionnelle indique maintenant ce que le changement toucherait dans le rapport : le nombre de visuels concernés et les pages où ils se trouvent, la plus chargée d’abord. C’est une liste d’endroits où regarder avant et après, pour comparer les totaux.
• L’information est volontairement prudente. Quand rien n’est trouvé, l’outil écrit « aucun visuel trouvé » et non « aucun impact » : une mesure est rattachée à sa table d’accueil, pas aux tables que sa formule parcourt, donc un visuel qui n’affiche qu’une mesure peut dépendre de ces tables sans apparaître. Et quand le fichier envoyé ne contient pas la couche rapport, l’outil le dit au lieu de laisser croire à une absence d’impact.

Corrigé

• La colonne calculée qui lit une autre table à travers une relation bidirectionnelle renvoyait à un constat sans action, alors que la même colonne pouvait déjà être déportée. Troisième correction du même défaut d’aiguillage - le remède existait, il n’était pas relié.

Ajouté

• Contrôle de chargeabilité après génération : si une correction introduit une dépendance circulaire (une formule qui finit par dépendre d’elle-même), la génération est annulée avec le détail de la boucle, au lieu de livrer un fichier que Power BI refusera d’ouvrir sans expliquer pourquoi.
• Le contrôle compare à l’ÉTAT D’AVANT, jamais à un idéal : un fichier déjà cassé à l’arrivée reste analysable et corrigeable. Seul l’ajout d’une rupture est refusé - sans quoi l’outil abandonnerait précisément les fichiers pour lesquels il est le plus utile.
• Nouvelle détection : relation entre deux types différents (une colonne texte reliée à une colonne entière, par exemple). Le fichier s’ouvre et fonctionne tant que toutes les valeurs se laissent convertir - le risque est DIFFÉRÉ. Le jour où la source livre une valeur non convertible, l’actualisation échoue, ou la ligne cesse silencieusement de correspondre et les totaux baissent sans alerte.
• Et sa correction est EMBARQUÉE, pas renvoyée à un geste manuel : le constat propose les deux façons d’aligner les types, et celle que tu choisis part dans le .pbip généré (type de stockage et requête Power Query mis à jour ensemble). Aucune n’est cochée d’avance, parce qu’elles n’ont pas le même solde - convertir en nombre allège mais peut perdre des lignes si une valeur n’est pas numérique, convertir en texte ne perd jamais rien mais alourdit la clé. Chaque option affiche donc son risque, et « sans risque » est écrit quand il n’y en a pas.

Modifié

• Deux défauts que nous pensions bloquants ne le sont pas, vérification faite sur huit rapports réels qui s’ouvrent tous sans problème : une relation entre une colonne texte et une colonne entière, et une mesure créée puis laissée vide. Power BI les tolère. Ils sont donc écartés du contrôle : un seul faux positif et l’outil refuserait de produire un fichier sain.

Ajouté

• Hiérarchie Excel construite sur une colonne masquée : le moteur prépare, pour chaque colonne, une structure réservée aux tableaux croisés dynamiques Excel branchés sur le modèle. Sur une colonne invisible qui ne sert ni de clé, ni de tri, ni de niveau de hiérarchie, c’est de la mémoire et du temps d’actualisation dépensés pour un usage qui n’existe pas. Désactivation automatique à la génération, sans toucher ni aux valeurs ni aux formules.
• Mesure appelée avec un nom de table devant : une mesure n’appartient à aucune table du point de vue du moteur. Cette écriture casse si la mesure est déplacée, et certains outils la refusent.
• Colonne lue sans sa table dans une mesure : le calcul casse le jour où une colonne du même nom apparaît ailleurs.
• Fonction de mise au point (EVALUATEANDLOG) restée dans le modèle : elle renvoie son argument sans le modifier, mais écrit une trace à chaque évaluation - donc à chaque requête de visuel. Un coût pur, sans contrepartie.
• Mesures en double : deux mesures qui calculent exactement la même chose. Chacune est un objet de plus à énumérer à chaque édition de formule, et surtout un risque de divergence le jour où le calcul change. La suppression reste manuelle et guidée : une mesure peut servir un rapport externe que le fichier ne montre pas.

Inclus

• Une détection a été volontairement ÉCARTÉE : la réécriture de la syntaxe « 1-(x/y) ». Sa correction change le résultat quand le dénominateur est vide ou nul - elle n’est donc pas mécaniquement réparable, et n’avait pas sa place dans ce lot.
• Les cinq règles ont été éprouvées sur huit rapports réels avant livraison. Ce contrôle a révélé que trois quarts des « mesures en double » annoncées étaient fausses : deux mesures ne différant que par le texte filtré (« Vendu » contre « Retourné ») passaient pour identiques. Corrigé, et verrouillé par un test.

Corrigé

• Les constats portant la même formule arrivent désormais sur une SEULE carte, qui s’annonce par le motif le plus fort et porte l’action. Une colonne calculée volatile (TODAY, NOW) n’est plus un cul-de-sac : elle affiche son enjeu réel et le bouton de déport, au lieu de renvoyer à une carte voisine où elle se perdait.
• L’enjeu affiché sur une carte groupée était le plus FAIBLE du groupe. L’ordre venait de la base, qui classait « moyen » avant « élevé ». Toutes les cartes regroupant plusieurs constats étaient concernées, pas seulement les colonnes volatiles.
• Une carte groupée s’annonçait par un décompte (« 2 optimisations sur cette formule ») qui ne disait ni laquelle pressait, ni pourquoi. Elle porte maintenant le motif le plus fort, le décompte passant en second.

Corrigé

• Retirer l’approbation d’un compte le déconnecte désormais immédiatement. Le droit d’accès est revérifié à chaque page, et plus seulement au moment de la connexion.
• Un compte supprimé est traité de la même façon : sa session en cours cesse aussitôt de fonctionner.

Inclus

• Deux choix de conception à ne pas défaire : cette vérification n’est jamais mise en cache (la fenêtre de cache serait exactement celle par laquelle passerait la personne révoquée, pour un coût d’une seule lecture en base), et le compte administrateur en est exclu (il n’existe pas dans la liste des utilisateurs, le contrôle le déconnecterait lui-même).

Corrigé

• Un filtre par type ne s’affiche plus que dans l’onglet qui contient réellement ces constats, et son compteur compte dans cet onglet. Fini le filtre qui promet du travail invisible.
• Le comportement voulu à l’origine est préservé : cliquer sur un type ne fait pas rétrécir les compteurs des autres types.

Corrigé

• Les formules volatiles servent désormais les objectifs « Fluidifier l’édition » (c’est leur raison d’être) et « Fiabiliser l’actualisation » (leur remède retire un recalcul). Elles ne servent PAS « Alléger le modèle » : le déport ne réduit pas la taille au repos, la colonne reste stockée.
• « Trop de visuels sur une page » sert maintenant l’objectif « Accélérer les visuels ». Chaque visuel déclenche sa propre requête : le constat y avait sa place et en était absent.

Ajouté

• Un garde-fou sur les objectifs, le troisième du genre : toute règle doit servir un objectif, ou être déclarée « hors objectifs » avec sa raison. Cinq le sont volontairement (quatre règles d’hygiène neutres sur tous les axes, et une alerte de justesse qui n’est jamais appliquée pour aller plus vite).

Inclus

• Vérifié sur un modèle réel de 85 tables : 12 formules volatiles détectées, correctement rattachées à leur étape et à leurs objectifs.

Corrigé

• Les colonnes et tables calculées volatiles s’affichent désormais dans l’étape « Alléger », avec les autres colonnes calculées - là où se trouve leur remède, le déport.

Ajouté

• Un garde-fou empêche qu’une nouvelle détection retombe en fin de parcours sans qu’on l’ait voulu : chaque règle doit être rattachée à une étape, ou déclarée explicitement comme laissée à la fin, avec sa raison. Deux règles le sont volontairement (le constat de synthèse sur la mémoire d’actualisation, et une alerte de justesse).

Modifié

• L’impact annoncé pour ces formules volatiles disait « édition plus courte » - le même niveau qu’un déport ordinaire, alors que le terrain a mesuré un facteur 15 à 20 sur ce seul axe. Il annonce désormais « nettement plus courte », et c’est la seule optimisation de l’outil dans ce cas. Le reste de son impact (taille, pic, visuels, extraction) reste celui d’un déport, puisque c’est le même remède.
• Ces constats portent leur propre étiquette « Formule volatile » dans le tableau récapitulatif, pour ne plus être confondus avec un déport ordinaire.

Ajouté

• Nouvelle détection « colonne calculée volatile » : une colonne calculée dont la formule appelle TODAY(), NOW(), USERNAME()… est revérifiée par le moteur, avec tout ce qui en dépend, à chaque ouverture du fichier et à chaque modification du modèle. Symptômes : éditions de formule interminables, ouverture interminable, fichier qui demande d’enregistrer alors que rien n’a changé.
• La détection couvre aussi les tables calculées volatiles. Les mesures ne sont pas signalées : elles ne stockent rien, ces fonctions y sont inoffensives.
• Le remède recommandé est le déport en Power Query ou SQL : les valeurs sont identiques (une colonne calculée avec TODAY() gèle de toute façon à l’actualisation - elle dit en réalité « date de la dernière actualisation »), et la revérification disparaît.

Inclus

• Chiffres du terrain, sur un modèle réel de 85 tables : 7 à 8 minutes par geste avant correction, 10 à 23 secondes après - un facteur 20, causé par 5 colonnes sur un millier. Le déport de l’outil en avait déjà éliminé 10 sur 15 sans le savoir.

Corrigé

• Le facteur de recalage se calcule désormais à un réglage de référence fixe, et non au réglage affiché. Il décrit l’écart entre le modèle de calcul et TA machine - pas le curseur qu’on est en train de bouger.
• Conséquence concrète sur un modèle réel : à 6 évaluations au lieu de 8, le pic actuel passe de 42,2 à 35,4 Go, et le plan complet de 22,8 à 20,7 Go - soit tout près du budget, là où il en restait à plus de 2 Go.

Inclus

• Contrepartie assumée : « aujourd’hui » ne colle à ta mesure qu’au réglage par défaut, celui auquel elle est censée avoir été prise. Simuler un autre parallélisme donne volontairement un autre chiffre - c’est tout l’intérêt du réglage.

Modifié

• Le classement suit désormais le POIDS libéré, mesuré, et ce poids s’affiche à côté du nombre (« libère 10 · 35 Mo »). Dix colonnes légères peuvent ne rien changer, là où une seule colonne lourde compte vraiment.
• Sans volumétrie importée, la carte garde le classement par nombre mais le DIT, et renvoie vers l’étape « Mesurer ». Elle ne fait plus passer un tri approximatif pour une priorité.

Corrigé

• Une durée écrite « 0,003 » était lue comme trois mille, soit mille fois trop. La virgule française était prise pour un séparateur de milliers. La convention se décide maintenant sur la colonne entière : une seule valeur claire suffit à trancher pour toutes les autres.
• Les relevés collés sont plafonnés à 4 Mo, et le dépassement est annoncé tout de suite au lieu d’échouer après l’envoi. La limite précédente (8 Mo) était supérieure à ce que le réseau laisse passer : elle ne pouvait pas s’appliquer.

Modifié

• Quand un relevé n’est pas reconnu, le message dit désormais ce qu’il a VU (colonnes trouvées, ou noms d’événements rencontrés dans le fichier .json), pas seulement ce qu’il attendait. Ces deux lecteurs n’ont encore jamais vu d’export réel : c’est ce qui permettra de les corriger du premier coup si ton relevé a une forme inattendue.

Modifié

• L’étape « Finaliser » s’ouvre désormais sur le contrôle des valeurs, avant la liste de ce qui reste à faire à la main. C’est l’ordre réel : on vérifie que le fichier est juste, puis on travaille dedans.
• Le contrôle reste accessible dans l’onglet Outils, à sa place habituelle.

Ajouté

• L’état du dernier contrôle est conservé et affiché : « contrôle passé le 29/07, aucun écart », ou la liste des objets qui divergent. Sans cette trace, une page rouverte le lendemain ne disait pas si le fichier avait été vérifié - et « je ne sais pas » se lit spontanément « tout va bien ».
• Un contrôle est marqué périmé dès que tu régénères : un verdict vert sur le fichier d’hier ne dit rien de celui de ce matin.
• Une pastille d’attention sur l’étape « Finaliser » tant qu’un fichier généré n’a pas été contrôlé. Elle ne s’allume jamais avant la première génération, pour ne pas devenir un décor qu’on apprend à ignorer.

Inclus

• Aucune de tes valeurs ne quitte ton navigateur : seuls les NOMS des objets qui divergent sont mémorisés, sur ta machine, à côté du relevé du fichier généré.

Corrigé

• Une réécriture qui met des colonnes de deux tables différentes dans un même filtre de CALCULATE est désormais refusée à la génération, avec son motif et le nom des deux tables. Elle vaut aussi pour les mesures, pas seulement les colonnes calculées.
• L’assistant sait maintenant qu’on ne retire pas un EARLIER en le remplaçant par la colonne : il doit passer par une variable intermédiaire, la seule forme équivalente. L’optimisation est donc conservée au lieu d’être perdue.
• Le contrôle ajouté hier ne pouvait pas attraper celui-ci : il compte les filtres, et leur nombre ne changeait pas. C’est le CONTENU d’un filtre existant qui devenait invalide.

Modifié

• Les commentaires des formules ne sont plus lus comme du code par ces contrôles : un nom de table cité dans un commentaire ne déclenche plus rien.

Corrigé

• Une réécriture de colonne calculée qui élargirait ses dépendances à toute la table est désormais REFUSÉE à la génération, avec son motif, plutôt que d’être écrite dans un fichier qui ne s’ouvrira pas. Sur le modèle de test, 13 réécritures sur 153 sont dans ce cas.
• Deux formes sont couvertes, parce que les deux étaient présentes : le filtre direct (« 'Table'[Colonne] = valeur ») et le retrait de filtre (ALLEXCEPT, ALL, REMOVEFILTERS).
• Le garde-fou existant ne pouvait pas le voir : il vérifie que la réécriture utilise les mêmes champs, et ici elle utilise exactement les mêmes. Le piège est dans le sens de l’opérateur, pas dans les noms cités.

Ajouté

• Les colonnes utilisées par un rôle de sécurité (sécurité au niveau des lignes) ne sont plus jamais proposées à la suppression : leurs expressions de filtre étaient tout simplement invisibles à l’analyse. Protection préventive - ce n’était pas la cause du problème du jour.

Corrigé

• Les comparaisons d’une colonne déportée à zéro (ou à une chaîne vide) sont protégées automatiquement, de même que les comparaisons entre deux colonnes de même type. Constaté sur un vrai rapport : un verdict passait de 235 lignes à 9, et 150 lignes changeaient de catégorie.
• La correction ne touche QUE ce qu’elle peut prouver : un test de vide (« = null »), une comparaison à une valeur non nulle, ou deux colonnes de types inconnus ou discordants sont laissés strictement intacts.
• Le type manquant des colonnes calculées (que Power BI ne stocke pas) est retrouvé dans la requête elle-même, là où la fusion vient de déclarer la colonne - sans quoi la moitié des cas resterait non réparable.
• La règle est aussi enseignée à l’IA, mais la protection ne repose plus sur elle : sur le fichier de terrain, elle avait appliqué l’idiome correct deux colonnes plus haut et l’avait oublié ici.

Modifié

• Quatre capacités absentes sont désormais décrites : rapatrier une valeur d’une autre table par une jointure, anticiper le pic mémoire de l’actualisation, préparer les déports dans le bon ordre en un clic, et ce qui reste à faire à la main avec son plan d’action.
• Une carte dit maintenant que tu gardes la main sur les coûts IA et sur la durée de conservation de tes fichiers.
• Le parcours décrit correspond à nouveau au parcours réel : l’étape finale « Finaliser » y figure, et deux cartes redondantes ont été fusionnées plutôt qu’empilées.

Modifié

• Le motif nomme la table en cause et distingue les deux cas réels : un filtre posé sur la table de départ (le calcul regroupe par les attributs de la ligne courante) et un filtre posé sur une table tierce (il restreint en passant par les relations du modèle).
• Sur le modèle de test, un seul message couvrant 6 colonnes se sépare en 4 diagnostics distincts, chacun nommant sa table.
• Là encore, aucune colonne de plus n’est déportable : ces formes demandent de reproduire la propagation par les relations, ce qui est un chantier à part entière et non un détail de message.

Modifié

• Les agrégats enfouis dans une variable intermédiaire sont maintenant relevés. Un calcul qui en cache ne peut donc plus être pris pour un cas « pur » et traité en oubliant une partie de lui-même.
• Les motifs de refus deviennent précis : sur le modèle de test, 7 colonnes sur 10 passent d’un « forme non reconnue » générique à un diagnostic exact (clé de jointure, forme du filtre, OU logique…).
• À noter : aucune colonne de plus n’est déportable pour l’instant. Ce qui bloque les deux colonnes les plus importantes est désormais nommé - leur clé de jointure est un calcul, pas une colonne - et c’est le prochain chantier.

Corrigé

• Une forme de fusion non reconnue affiche désormais « Fusion non générée » et son motif, au lieu de laisser la carte vide. Sur le modèle de terrain, dix colonnes étaient dans ce cas - dont les deux qui en bloquent dix-neuf autres à elles seules.
• Le motif dit aussi ce qu’il n’est pas : ces formes ne sont pas un défaut de ton modèle, mais un cas que l’outil ne couvre pas encore.

Corrigé

• Une fusion mixte refusée par l’IA n’est plus resoumise à l’identique lors d’une campagne suivante. Sur le modèle de terrain, huit colonnes refusées la veille étaient reproposées le lendemain pour ~0,17 $.
• Le refus reste PÉRISSABLE : dès qu’une colonne dont le calcul dépend est déportée, le contrat annoncé à l’IA change et la tentative se rouvre toute seule. Un simple drapeau « déjà refusé » aurait cassé le mécanisme des vagues successives.
• Ces colonnes sont comptées sur une ligne à elles dans l’écran de confirmation (« Déjà refusées à l’identique, non refacturées ») : les fondre dans « sans recette applicable » les aurait fait changer de case sans explication.

Modifié

• Le compteur de déport ne rapporte plus qu’aux colonnes réellement déportables : « 187/290 (+181 hors de portée) » au lieu de « 187/471 ». Le verdict est le même que celui affiché depuis toujours sur chaque carte (« À garder en DAX / à la source »), simplement additionné.
• Les colonnes hors de portée restent annoncées et explicables au survol : elles sortent du ratio, pas de la vue - une colonne qui disparaîtrait d’un compte sans explication serait pire que le chiffre décourageant qu’on corrige.
• Les textes de conservation annonçaient « 7 jours » partout alors que tu règles la durée jusqu’à 90 jours depuis la v1.134 : ils disent maintenant que 7 jours est le défaut, et les messages d’expiration ne citent plus de durée en dur (ils la citaient fausse au moment précis où tu cherchais à comprendre).

Ajouté

• Un bouton « Tout afficher » dans les listes de constats : les parcourir par paquets de 20 demandait 23 clics sur un gros modèle. Le pas de 20 reste le défaut (monter des centaines de cartes d’un coup ralentit la page) - la version lente devient un choix annoncé.

Ajouté

• Une carte « Par où commencer » qui liste les colonnes bloquantes, classées par nombre de colonnes qu’elles libèrent. Sur un modèle réel : 5 colonnes en bloquent 26 autres, dont une seule qui en libère 10.
• Les colonnes qui attendent PLUSIEURS dépendances sont comptées à part (« + N partiellement ») : traiter un seul bloqueur ne les libère pas, et te le promettre serait faux.
• Un bloqueur lui-même bloqué est signalé comme tel, et ceux que tu peux traiter tout de suite passent devant.

Corrigé

• L’ordre dans lequel tes tables sont traitées tient désormais compte de TOUT ce qu’une fusion lit ailleurs : plusieurs colonnes d’une même table, jointures multiples, tables traversées par une chaîne de relations, et colonnes agrégées avec leurs filtres.

Corrigé

• Les fusions qui traversent une chaîne de relations sont maintenant réellement appliquées. Le contrôle qui vérifie qu’une colonne existe avant d’écrire une jointure ne reconnaissait pas la clé fabriquée par le premier passage : il la prenait pour une colonne manquante et écartait la colonne entière.
• Le compte annoncé hier (15 colonnes) n’a pas été retrouvé en rejouant l’analyse sur ton rapport : il y en a 7. Trois sont générables tout de suite ; les quatre autres attendent que la colonne qu’elles vont chercher soit elle-même sortie du calcul DAX, et l’indiquent désormais avec ce motif précis.

Modifié

• Une colonne en cascade ne pénalise plus les autres colonnes de sa table. Elle est écrite à part : sans cela, une seule d’entre elles faisait basculer toutes les fusions de la même table vers la méthode la plus lente, celle qui relit la source une seconde fois.

Inclus

• Les refus sont maintenant motivés par la vraie raison. Une colonne écartée te dit quelle clé ou quelle colonne lui manque et sur quelle table, au lieu d’un message qui désignait une colonne inexistante.

Corrigé

• Choisir « À faire à la main » sur une étape puis passer sur une étape 100 % automatique donnait un écran vide et sans issue : le travail de l’étape était invisible et elle semblait terminée. La bascule retombe maintenant sur le côté qui a quelque chose à montrer.

Inclus

• Ton choix est conservé partout où il a un sens : sur une étape qui a bien les deux, tu restes sur l’onglet que tu avais sélectionné.

Ajouté

• Les fusions qui traversent une chaîne de relations sont désormais appliquées dans le .pbip généré. Sur le rapport qui a servi au diagnostic, cela concernait 15 colonnes calculées jusqu’ici bloquées.

Inclus

• Quand la table de départ lit une requête SQL, ce cas précis reste traité en Power Query plutôt qu’à la source : la clé intermédiaire n’existe pas dans ta requête d’origine, et l’y référencer ferait échouer l’actualisation.

Corrigé

• Une relation déclarée « un-à-plusieurs » n’est plus invisible : la fusion correspondante était refusée alors que la relation existait.
• Quand ta formule va chercher une valeur à travers plusieurs relations en cascade (modèle « en flocon »), l’outil te dit désormais quelle est la chaîne et pourquoi il ne sait pas encore la traiter, au lieu de te faire croire à un défaut de ton modèle.

Ajouté

• L’import de l’Analyseur de performances de Power BI Desktop (onglet Affichage), qui donne la durée réelle des requêtes derrière chaque visuel.
• L’import des durées des diagnostics Power Query : le temps réellement passé à extraire et transformer chaque table. C’est le même geste que pour la mémoire, sur une autre table du dossier Diagnostics.
• Un verdict chiffré avant/après une fois les deux relevés donnés, avec le détail des durées.

Modifié

• Quand une durée d’extraction a été mesurée sur une table, la carte du constat affiche la MESURE au lieu de l’estimation.
• Une durée mesurée sur les visuels reste affichée au niveau du rapport, jamais sur une carte : elle se rapporte à un visuel, alors que les constats portent sur des formules et des colonnes. L’attribuer à une optimisation précise serait plus flatteur, mais faux.

Corrigé

• Importer une mesure pouvait en effacer une autre en silence (par exemple ta volumétrie effaçant ta mesure de mémoire). Tout ce qui n’est pas explicitement remplacé est désormais conservé.
• Les nombres à virgule des relevés collés étaient mal lus : « 1,5 » devenait 15.

Ajouté

• Une durée de conservation réglable par rapport (7, 14, 30, 60 ou 90 jours), dans l’écran « Outils ». Le plafond de 90 jours se compte depuis l’envoi du fichier : il ne peut pas être repoussé indéfiniment.
• Un bouton « Supprimer le fichier maintenant », sans attendre l’échéance. Ton analyse reste, comme toujours.
• Une alerte avant suppression, réglable sur ta page « Mon compte » (jamais, 1, 2, 3, 7 ou 14 jours avant). Elle arrive dans la cloche en haut de l’écran.
• Un journal, par rapport, de tout ce qui a touché à la durée de vie du fichier : tes propres gestes ET les suppressions automatiques, avec la date et l’échéance avant/après.
• Une vraie section « Durée de conservation » dans la politique de confidentialité : ce qui est gardé, combien de temps, et comment le vérifier.

Corrigé

• Quand la suppression d’un fichier échoue (incident chez l’hébergeur du stockage), tu es maintenant prévenu au bout de trois nuits. Avant, la tentative se répétait indéfiniment en silence et le fichier restait au-delà de la durée annoncée sans que personne ne le sache.

Corrigé

• « Date/heure automatique » affiche son vrai impact : mémoire libérée (chiffrée), pic d’actualisation en baisse, et surtout une attente bien plus courte quand tu écris une formule dans Power BI Desktop - c’est le seul geste qui retire des centaines d’objets cachés d’un coup.
• Les visuels et la durée d’extraction restent annoncés à « inchangé » pour cette optimisation : ces tables cachées ne sont ni interrogées par tes visuels, ni extraites de ta source. Rien n’est promis qui ne soit vrai.

Ajouté

• La marche à suivre s’affiche sous une optimisation que la génération n’a pas pu appliquer, quand le geste reste faisable à la main (cas du « SELECT * » laissé tel quel).

Modifié

• Les modes d’emploi devenus inutiles ont été supprimés : ils décrivaient des réglages (format d’affichage, résumé par défaut, date/heure automatique, relation inactive) et des suppressions d’objets que le fichier généré applique désormais sans toi.

Ajouté

• Une bascule « Embarquable dans le .pbip » / « À faire à la main » en tête de chaque étape, avec le nombre de chaque côté.
• Une étape « Finaliser » qui rassemble tout ce qui restera à faire dans Power BI, avec son plan téléchargeable.

Modifié

• L’étape « Générer » ne parle plus que du fichier : elle renvoie vers « Finaliser » pour le reste.
• La liste de « Finaliser » se réduit d’elle-même dès qu’une formule reçoit une proposition de réécriture ou qu’un déport est coché - la page l’explique, pour que cette disparition ne passe pas pour un défaut.

Corrigé

• Effacer les mesures importées demande confirmation : c’est une collecte manuelle que l’app ne sait pas refaire à ta place.
• L’impact de ta sélection, le simulateur d’actualisation et les clés de substitution ne disparaissent plus en silence quand leur chargement échoue : ils l’annoncent et proposent de réessayer.
• Les champs du simulateur se saisissent enfin au clavier (taper 128 était impossible), et le pic mesuré accepte la virgule française (39,8).
• Un traitement IA en masse peut être arrêté en cours de route : ce qui est déjà fait est conservé.
• Le vert des gains est lisible en thème clair (il était sous la moitié du seuil recommandé).
• « Déporter » et « Convertir » ne désignent plus la même action par deux mots différents.

Modifié

• Demander un nouveau lien de réinitialisation annule le précédent : un seul lien valide à la fois.
• Un lien de réinitialisation ne peut réellement servir qu’une fois, même si on le soumet deux fois en même temps.
• L’adresse technique du compte administrateur ne peut plus être utilisée à l’inscription.
• Les fichiers dont le contenu compressé annonce une taille irréaliste sont refusés plus tôt.
• Les liens périmés et les réservations d’analyse IA abandonnées sont nettoyés chaque jour.

Corrigé

• Les alertes de la revue de cohérence (IA) survivent à une relance d’analyse, avec leur statut - plus besoin de relancer la revue.
• Exception volontaire : si la formule concernée a changé dans le nouveau fichier, l’alerte est abandonnée. Elle décrivait l’ancien calcul, la garder induirait en erreur ; relance la revue pour analyser le nouveau.

Corrigé

• Deux colonnes dont l’une contient l’autre dans son nom ne cassent plus la requête générée (l’actualisation de la table entière échouait).
• Les tables dont la source est écrite en une seule ligne sont de nouveau reconnues : leur requête était confondue avec le nom de la base, ce qui rendait le déport et la fusion indisponibles sans explication, et pouvait abîmer le fichier généré.
• Règle unique et affichée : cocher propose, valider engage. Une option cochée sur une carte non validée n’est pas appliquée - et elle est désormais LISTÉE dans le récapitulatif, au lieu de disparaître en silence.
• À l’inverse, une carte remise à « ignoré » n’est plus appliquée quand même (c’était le cas des fusions et des conversions de tables).
• Cocher un déport marque bien la carte comme validée à l’écran, sans recharger le rapport.
• Relancer la traduction d’une table calculée ne décoche plus sa conversion.

Corrigé

• Une formule déjà réécrite ne repropose plus de la réécrire pendant le chargement de sa proposition : la carte annonce l’attente.
• Si le chargement des propositions échoue, la carte le dit et offre un bouton « Réessayer », au lieu de rester silencieusement sur le bouton payant.

Corrigé

• Le plafond de dépense IA tient désormais aussi quand plusieurs analyses partent en même temps : chaque appel met de côté son budget avant de commencer, et pas plus de 12 analyses IA tournent à la fois sur un compte.
• Relancer l’analyse deux fois en même temps (deux onglets, un double-clic) n’est plus possible : la seconde attend son tour, avec un message clair.
• Une analyse interrompue ne laisse plus le rapport bloqué en « analyse en cours » : il redevient analysable au bout d’un quart d’heure.
• Une relance d’analyse ne peut plus vider un rapport de ses constats si elle échoue en cours de route, y compris sur les très gros modèles (au-delà de 4 000 constats, l’enregistrement échouait d’un bloc).

Corrigé

• Deux résumés d’une même table avec des filtres différents ne sont plus confondus : chacun garde son propre périmètre dans le fichier généré. Les filtres concernés sont ceux ajoutés récemment (plus grand que, différent de, listes de valeurs, cases vides).
• Le ménage du 7e jour ne supprime plus que le fichier Power BI d’origine : l’analyse, les validations, les réécritures et les mesures importées restent en place, comme l’app l’a toujours annoncé.
• Si la suppression du fichier échoue, elle est retentée le lendemain au lieu d’être abandonnée.

Modifié

• Les propositions et explications de l’IA sont chargées à part : elles ne sont plus retéléchargées à chaque changement de statut ou déport (une trentaine de points de rechargement dans la page).
• Le traitement groupé des réécritures ne relit plus la totalité des constats à chaque paquet : il ne charge que les formules qu’il va traiter.
• Aucun changement visible dans l’interface : mêmes cartes, mêmes décomptes, mêmes propositions.

Ajouté

• Une base de données locale pour le développement, pour ne plus travailler contre la base de production (et ne plus en consommer le quota).

Ajouté

• Les formules qui neutralisent les relations pour ne garder que leur rapprochement explicite (ALLCROSSFILTERED, REMOVEFILTERS, ALL) sont enfin déportables : c’est exactement ce que fait le déport.
• Le périmètre d’un regroupement accepte les comparaisons : plus grand que, plus petit que, différent de, dans une liste, vide ou non vide.
• Garde-fou sur les cellules vides : Power BI compte une cellule vide comme un zéro avant de comparer, une base de données non - sans correction, des lignes auraient disparu du calcul en silence. Chaque condition emporte désormais son verdict et la requête est complétée quand il le faut.
• Restent volontairement refusées : les comparaisons d’ordre sur du texte (Power BI et le serveur ne trient pas pareil), les fonctions appliquées à la colonne, et les comparaisons entre deux colonnes.

Corrigé

• Une liste de valeurs entre accolades ne coupe plus la formule en deux : ses virgules étaient prises pour des séparateurs.
• Quand une condition n’est pas déportable, le message cite la condition en cause au lieu d’un motif générique.

Corrigé

• Les pages « Mesurer » et « Générer » utilisent le même recalage sur ta mesure réelle : leurs chiffres sont enfin comparables.
• La double copie du modèle n’est jamais recalée (c’est une quantité sûre), et une mesure prise sur un fichier déjà optimisé ne fausse plus la page Mesurer.
• Un CALCULATE enveloppant sans filtre est compris pour ce qu’il est - un filtrage par la ligne courante à travers les relations - et non confondu avec son contenu, ce qui aurait compté toute la table.

Ajouté

• Une colonne qui lit une valeur ailleurs ET compte des lignes dans une autre table est désormais traitée en entier, au lieu de laisser le comptage en DAX.
• Plusieurs comptages différents sur une même colonne (tables, clés ou filtres distincts) sont acceptés : chacun devient son propre regroupement.

Corrigé

• Une colonne à comptage qui ne peut pas partir en SQL n’entraîne plus le refus de toutes les autres fusions de sa table : elle seule est écartée, et l’outil le dit.
• Une colonne écartée n’est plus marquée comme provenant de la requête : elle serait apparue vide après actualisation.

Ajouté

• Une colonne qui joint plusieurs tables produit plusieurs jointures dans la requête SQL, avec une seule lecture de la source.
• Deux colonnes qui joignent la même table de la même façon continuent de partager une seule jointure.

Corrigé

• Les clés de toutes les jointures entrent dans les vérifications de sûreté, et plus seulement celles de la première : un oubli n’aurait pas déclenché d’erreur, mais aurait donné des valeurs fausses.
• Quand une seule des tables concernées n’est pas éligible au SQL, tout le lot repart proprement en Power Query - jamais une requête à laquelle il manquerait une jointure.

Ajouté

• Une colonne qui lit plusieurs tables reçoit une jointure par table, au lieu d’être refusée.
• Deux recherches vers la même table mais sur des clés différentes deviennent deux jointures, au lieu d’en laisser une dans le calcul restant.
• Deux colonnes qui joignent la même table de la même façon continuent de partager une seule jointure : rien n’est écrit en double.

Corrigé

• Le contrôle de sûreté qui vérifie que chaque colonne utilisée existe bien dans la requête couvre maintenant les jointures supplémentaires.
• Le chemin « à la source (SQL) » refuse explicitement ces fusions et se replie sur Power Query, au lieu de les ignorer sans le dire.

Inclus

• Prochaine étape du chantier : les comptages qui parcourent une autre table ligne par ligne, encore laissés en DAX.

Ajouté

• Étape 3 du déport : « Déporter les tables calculées en Power Query », en lot, avec le nombre exact et le coût annoncés avant de lancer.
• Les tables dont le refus ne dépend pas des déports sont écartées du lot et annoncées comme telles, au lieu de dépenser de l’IA pour un échec certain.

Modifié

• Les colonnes concernées par un changement de type sont désormais listées DANS leur carte d’action groupée, à côté du réglage qui les gouverne, au lieu d’être ailleurs sur la page.
• L’avertissement dit franchement ce qui est perdu : « date-heure → date » supprime l’heure, « flottant → nombre décimal fixe » ne garde que 4 chiffres après la virgule. Chaque cas indique quand il faut décocher.
• Chaque clé de relation en texte affiche son propre impact (taille, pic d’actualisation, visuels, extraction, édition), au lieu du seul total de toutes les clés.

Corrigé

• Le bouton « Tout préparer » renvoyait vers la mauvaise étape pour cocher la conversion d’une table calculée.

Ajouté

• Nouvel objectif « Fluidifier l’édition » et nouvel axe d’impact « Attente à l’édition d’une formule » : le confort de conception devient un sujet à part entière, à côté de la mémoire, de l’actualisation, des visuels et de l’extraction.
• Nouvelle analyse qui compte les objets du modèle (tables de dates cachées de « Date/heure automatique » incluses) ET la densité des liens entre colonnes calculées, en nommant la cause dominante et en classant les remèdes du plus rentable au moins rentable.
• Supprimer une mesure affiche désormais un gain : celui du confort d’édition, le seul qu’une mesure puisse apporter puisqu’elle n’occupe pas de mémoire.

Corrigé

• Le décompte par axe de la page « Générer » se déduit maintenant de la liste des axes : tel qu’il était écrit, il aurait oublié le nouvel axe sans rien signaler.

Inclus

• Les rapports déjà analysés doivent être ré-analysés pour voir la nouvelle analyse apparaître. Le nouvel objectif, lui, fonctionne tout de suite : il regroupe des recommandations déjà présentes.

Corrigé

• Une clé de relation non convertible n’est plus listée qu’une seule fois par motif, au lieu d’une fois par relation où elle apparaît.
• Le nombre affiché de clés non convertibles est désormais juste (il comptait les doublons).

Ajouté

• « Tout réécrire en DAX » (étape Affiner) : traite d’un coup les formules qui ne peuvent pas sortir du modèle, avec le nombre exact et le coût annoncés avant de lancer, et une reprise automatique des échecs passagers.
• Le récapitulatif distingue les formules écartées par le garde-fou de fidélité (la réécriture changeait les champs lus, donc le résultat aurait pu bouger : c’est un refus volontaire) des vraies pannes techniques.

Corrigé

• Les colonnes encore déportables sont écartées du lot de réécriture et annoncées comme telles : mieux vaut les déporter que les réécrire. Sans ce tri, l’outil proposait de dépenser de l’IA à contresens de son propre conseil.
• Le bandeau de l’action groupée n’affiche plus de total : il annonçait un chiffre que l’aperçu contredisait ensuite (477 contre 191).

Ajouté

• Bouton « Tout préparer » : déroule seul les fusions puis les déports, en boucle, jusqu’à ce qu’une vague n’apporte plus rien - avec le coût annoncé au fur et à mesure, un arrêt possible à tout moment sans rien perdre de ce qui est déjà coché, et les conversions de tables calculées retentées au passage.
• Une conversion de table calculée refusée parce qu’une colonne n’était pas disponible en Power Query le dit maintenant dès que cette colonne est déportée : le blocage est nommé, les colonnes concernées listées, et un bouton propose de retenter.
• Les conversions refusées AVANT cette nouveauté sont proposées elles aussi à une nouvelle tentative dès que des colonnes ont été déportées, avec un libellé qui dit franchement qu’on ne connaît pas le motif d’origine - sans quoi les campagnes déjà commencées auraient gardé des refus dépassés sans le savoir.

Modifié

• Les deux actions groupées de déport sont numérotées et remises dans l’ordre utile : les fusions (1) avant le déport Power Query (2). Elles étaient affichées à l’envers, ce qui invitait à travailler à contresens.
• Après chaque déport, l’aperçu est recalculé immédiatement (gratuit) et le récapitulatif annonce combien de colonnes cette vague vient de débloquer, avec un bouton pour enchaîner - ou dit explicitement que la chaîne est allée au bout.
• Le récapitulatif des fusions propose d’enchaîner directement sur le déport Power Query, au lieu de laisser deviner que c’est l’étape suivante.

Corrigé

• Une fusion substitue désormais TOUTES les lectures RELATED / LOOKUPVALUE vers la même table (un champ d’appoint par colonne lue, une seule jointure) : le reste du calcul devient local à la ligne et la traduction aboutit.
• Le déport en masse annonce à l’IA les mêmes champs d’appoint, avec les mêmes types, que le flux individuel (constructeur partagé) - il annonçait un seul champ typé « texte » par défaut, d’où les refus en série.
• Chaque refus de traduction affiche maintenant son motif dans le récapitulatif, au lieu d’un libellé générique.

Corrigé

• Les colonnes déportées par fusion ou en SQL comptent comme disponibles pour les déports Power Query qui les lisent : les chaînes « colonne facile → colonne fusionnée » se débloquent, à la génération comme dans la carte « Déporter en masse ».
• Les fusions s’écrivent désormais avant les déports Power Query - condition du déblocage ci-dessus, et correction d’un défaut discret : sur une table ayant les deux, la fusion retombait silencieusement en jointure Power Query au lieu du chemin SQL.
• Nouveau garde-fou à l’écriture du fichier : toute référence vers une colonne absente de la requête écarte cette seule colonne avec un motif visible dans le récapitulatif - plus aucun scénario où un fournisseur qui échoue casse l’actualisation en cascade.
• Libellé corrigé sur la carte « Déporter en masse » : « déjà cochées pour le déport (rien à refaire) » au lieu de « déjà marquées (ignorées) ».

Ajouté

• Nouvelle alerte « Valeurs lues dans une table dédoublonnée arbitrairement » : quand une requête supprime les doublons sur une clé, toutes les colonnes calculées qui y lisent une autre valeur ont un résultat potentiellement instable. L’alerte est groupée par table consultée (une vérification par table, pas une par colonne) et liste les colonnes concernées.
• Requête de vérification fournie et copiable : elle interroge la base, seul endroit où l’ambiguïté est encore visible - dans le modèle chargé, le dédoublonnage a déjà eu lieu, une requête DAX répondrait toujours « rien à signaler ». Quand la requête source ne s’y prête pas, la marche à suivre dans Power Query est expliquée.
• Guide d’application : vérifier d’abord, puis remplacer la lecture par une règle explicite (« existe-t-il au moins une ligne avec la valeur attendue ? », ou un maximum assumé). Ces deux formes redeviennent reproductibles - et pbi-optimizer sait les déporter en SQL.
• Contrôle de fidélité : un écart sur une de ces colonnes est désormais étiqueté « compatible avec un dédoublonnage arbitraire » et affiché avant la liste des optimisations suspectes, pour ne plus perdre de temps à en désactiver une qui n’y est pour rien.

Ajouté

• Une colonne peut désormais déporter PLUSIEURS agrégats différents (MAX de deux colonnes distinctes, MIN et MAX de la même colonne…) en une seule jointure GROUP BY, à condition qu’ils partagent table, clés et filtres.
• Chaque agrégat reçoit son propre champ d’appoint, nettoyé en fin de requête ; le reste du calcul les référence individuellement, avec le type produit par chaque agrégat.
• Toutes les preuves sont étendues : chaque colonne agrégée supplémentaire est vérifiée en sortie de requête à la planification ET à l’application du fichier.

Ajouté

• Fusion-agrégat mixte : une colonne « SI compte > 0 ALORS 1 SINON 0 » est déportée en deux morceaux - l’agrégat en SQL (GROUP BY côté serveur), le reste traduit en Power Query ligne à ligne, comme les fusions mixtes classiques.
• Filtres constants reconnus et poussés en SQL (WHERE avant l’agrégat), RELATEDTABLE accepté seulement si la relation du modèle le prouve redondant, agrégat répété remplacé partout par un seul champ d’appoint.
• Cas limite verrouillé : un compte sans correspondance est livré 0 (pas vide) quand un calcul le compare ensuite - un vide ferait échouer l’actualisation ; le compte « pur » garde le vide, fidèle au DAX.

Ajouté

• Fusion-agrégat : les colonnes qui agrègent une autre table par clé (MAX, MIN, SOMME, MOYENNE, COMPTE, valeur unique) sont proposées comme fusions et déportées en SQL (GROUP BY côté serveur, une seule lecture de la source). Reconnaissance déterministe des formes DAX du terrain, y compris les VAR et les commentaires.
• Prudence sur preuve : tout ce qui n’est pas une conjonction d’égalités simples (OU logique, comparaisons, formes mixtes IF/SWITCH, agrégat sur la table elle-même) est refusé avec son motif - la colonne reste en DAX, résultat inchangé. Pas de repli Power Query pour les agrégats : SQL ou rien.
• Le panneau d’assistance affiche la recette d’agrégat (fonction, clés, table) avant l’opt-in, comme pour les fusions classiques.

Ajouté

• Fusion déportée en SQL : la jointure (LEFT JOIN dédupliqué sur la clé, comparaison tolérante aux vides) est injectée dans la requête SQL native de la table de départ quand les deux tables viennent du même serveur et de la même base. La ligne de génération l’indique : « (jointure déportée en SQL) ».
• Éligibilité prouvée, jamais devinée : requête SQL native unique de chaque côté, clés et colonne rapatriée démontrées présentes dans les sorties des requêtes (alias AS sous toutes leurs formes, étoiles sur nos propres enveloppes suivies récursivement), étapes Power Query limitées à la déduplication et au retypage inoffensif. Quatorze scénarios à risque identifiés et testés (CTE, ORDER BY final, doublons de noms, re-téléversement…).
• Cas mixte : seul le reste du calcul (déjà row-local) demeure en Power Query ; la lecture de l’autre table, elle, ne se fait plus qu’une fois.

Corrigé

• Une fusion vérifie désormais, au moment exact où sa jointure s’écrit dans le fichier, que chaque colonne qu’elle référence existe réellement dans la requête de l’autre table - y compris quand un déport prévu en amont a échoué entre-temps. À défaut : refus motivé, colonne conservée en DAX, actualisation préservée.
• Les fusions qui dépendent l’une de l’autre s’appliquent dans le bon ordre (celle qui fournit une colonne avant celle qui la consomme), pour ne pas refuser à tort un enchaînement légitime.

Ajouté

• Option « Retirer aussi ces colonnes des requêtes SQL » à la génération : la ligne de chaque colonne supprimée est retirée du SELECT de sa requête source, uniquement sur preuve (colonne citée une seule fois, dans la liste du SELECT, aucune autre requête ne la consomme, aucune autre colonne du modèle ne lit la même colonne source). Seize scénarios à risque identifiés et testés, du style de virgule aux identifiants à crochets contenant une apostrophe.
• Traçabilité : un commentaire en tête de requête indique la date, le compte et les colonnes retirées.
• Le rappel « à retirer de tes requêtes » se synchronise : une colonne retirée automatiquement n’y figure plus, les refus y restent avec leur motif.

Corrigé

• Une fusion n’est plus appliquée que si l’outil peut PROUVER que la colonne cherchée et les clés de jointure existeront dans la requête de l’autre table. Dans le doute, la colonne reste en DAX et la raison est affichée : on renonce à une optimisation plutôt que de casser l’actualisation.
• Les noms de colonnes et de tables sont désormais comparés en ignorant les espaces en trop, la casse et la façon dont les accents sont encodés. Un nom irrégulier faisait échouer la recherche dans le modèle, et une colonne introuvable était prise pour une colonne source, donc supposée disponible.
• Une colonne que la requête expose sous un autre nom que celui du modèle fait aussi renoncer à la fusion : la jointure écrirait un nom que la requête ne connaît pas.

Modifié

• Retrait du « combo table lourde » (optimiser la source puis déporter), devenu injoignable : ni page ni bouton n’y menait plus.

Corrigé

• « Génère le .pbip depuis la barre en bas d’écran » : cette barre n’existe plus, la génération se fait à la dernière étape du parcours.
• Les avertissements sur les colonnes supprimables renvoyaient « ci-dessus » vers les rapports connectés, qui vivent maintenant à l’étape Mesurer.
• Sur l’étape Mesurer, trois renvois désignaient « plus haut » ou « plus bas » des cartes situées à l’inverse (le simulateur d’actualisation, les cartes Tables et Colonnes, l’import des mesures).
• Page d’accueil : « un réglage table par table pour les grosses tables » décrivait le seuil de déport, supprimé à la version précédente.

Modifié

• Page d’accueil : le parcours décrit correspond de nouveau à l’application (mesure d’abord, puis objectif, puis cinq étapes ordonnées avec l’impact sur quatre axes). La liste de ce que contient le fichier généré était incomplète : les tables calculées, les changements de type et les clés de substitution y figurent désormais.
• Page d’accueil : le contrôle des réécritures de requêtes ne se contente plus d’un verdict « identique », il mesure le gain réel - c’est dit.
• Page d’accueil : l’invitation finale annonce que chaque inscription est validée manuellement, au lieu de promettre une analyse « en quelques minutes ».

Modifié

• Le seuil de déport (« ne pas déporter au-delà de N lignes ») est retiré, avec son réglage et ses tables « forcées ». Ce que tu coches est appliqué, sans exception.
• Le coût d’un déport sur l’extraction suit désormais la taille de la table : « nettement plus longue » sur une grosse table, là où toutes s’affichaient pareil. Le déport « à la source (SQL) » reste au coût le plus faible, car c’est le serveur qui calcule.
• Une colonne traduisible « à la source (SQL) » annonce son coût réel dès avant d’être cochée, au lieu du coût d’un calcul Power Query.
• L’étiquette « Expérimental » est remplacée par « Hors fidélité garantie » là où elle manquait, et retirée là où le texte le disait déjà. Elle faisait douter d’une fonction qui marche sans dire quoi faire ; la nouvelle formulation nomme le seul risque qui subsiste (DAX et Power Query peuvent différer) et l’action qui le lève (actualiser, puis lancer le contrôle de fidélité).

Corrigé

• Le déport en masse, les changements de type et les clés de relation ignoraient le filtre d’impact : ils restaient à l’écran alors qu’aucune de leurs colonnes ne passait le filtre. Les cinq blocs suivent désormais la même règle.
• Un bloc qui commande des cartes déjà listées (le déport, par exemple) ne s’ajoute plus au décompte de l’étape : ses colonnes y étaient comptées deux fois.

Ajouté

• Un cadre commun « Action groupée » pour les cinq blocs de traitement en masse : on voit d’un coup d’œil ce qui agit sur un lot et ce qui agit à l’unité.
• Chaque bloc est repliable et se souvient de son état, avec un bandeau de résumé qui reste lisible replié (« 89 cochées pour le déport, dont 55 à la source SQL ») et son impact estimé sur les 4 axes.
• Ligne « N actions groupées masquées par ton filtre - afficher quand même » : une action écartée par un filtre est annoncée, jamais escamotée.

Corrigé

• Lisibilité des encadrés d’avertissement en thème sombre : ils étaient à la limite de l’invisible (contraste mesuré à 1,1 pour 1, désormais 8,6 à 9,4). Corrigé dans les 20 fichiers concernés.
• « Déport non recommandé » ne s’affiche plus que sur les colonnes réellement refusées, avec la raison du refus.

Ajouté

• Un verdict de déport unique, partagé par l’affichage et par la génération : les deux ne peuvent plus se contredire sur ce qu’une colonne sait faire.

Corrigé

• « Déport non recommandé » ne s’affiche plus que si aucune voie n’aboutit, ni Power Query ni SQL.
• La carte montre désormais la voie réellement retenue (souvent le SQL, calculé par le serveur) avec son expression et son explication, ainsi que la case à cocher du déport — tout cela était masqué.
• Quand un refus n’a aucune raison enregistrée, la carte le dit au lieu d’afficher une alerte vide.

Modifié

• « Impact réel critique / élevé / moyen / faible » devient « Enjeu critique / élevé / moyen / faible », y compris sur les rapports sans mesures importées.
• Le chiffre qui accompagne l’étiquette (poids en mémoire, valeurs distinctes) et le classement des optimisations sont inchangés.

Corrigé

• Lisibilité des étiquettes rouges en thème clair : elles étaient sous le seuil de contraste recommandé (mesuré à 3,6:1, désormais 4,9:1). Le correctif profite aussi aux autres étiquettes rouges de l’app (« Calculée morte », « Erreur », enjeu des requêtes SQL, alertes mémoire).

Corrigé

• Le compteur d’étape ignorait les colonnes supprimables et les requêtes SQL : il pouvait afficher 0 alors que 174 optimisations et 49 Mo de gain étaient sur la page.
• Une liste vidée par le filtre ne contredit plus le bloc affiché au-dessus : le message distingue « rien à traiter ici », « ton filtre ne laisse rien passer » et « seules les cartes sont écartées ».

Ajouté

• Les blocs groupés affichent leur impact estimé sur les 4 axes, calculé à partir de leurs propres éléments (donc toujours cohérent avec ce qu’ils contiennent).
• Ils sont pris en compte par le filtre et par le compteur de chaque étape.

Modifié

• Un seul bouton « Optimiser avec l’IA », qui traite 4 sous-requêtes à la fois.
• L’ancien mode « tout en un appel » est retiré : au-delà de la durée maximale il perdait la totalité du travail, et il ne vérifiait ton plafond de dépense qu’une seule fois avant de lancer jusqu’à une centaine d’appels.
• Le bandeau d’avancement indique le nombre de sous-requêtes en cours de traitement.

Corrigé

• Brique de connexion mise à jour : les 3 alertes critiques et 1 alerte importante sont fermées. L’audit passe de 11 à 4 alertes, sans plus aucune critique.
• Les correctifs portent sur la validation des adresses email, la gestion d’un jeton d’authentification mal formé, et le fait qu’une session en erreur ne doit jamais compter comme une session valide.
• Vérification faite : ton application n’était pas exposée à la faille la plus grave, car tous ses verrous exigent un utilisateur identifié et pas seulement la présence d’une session.

Corrigé

• Un outil de développement était livré avec l’application alors qu’il n’y sert pas : retiré du paquet déployé (17 alertes de sécurité en moins, et un déploiement plus léger).
• Framework du site mis à jour vers sa version corrigée : fermeture de trois failles importantes (dont une permettant de faire émettre des requêtes non prévues par le serveur) et de cinq alertes moyennes.
• Outil de mise en forme des styles mis à jour.

Ajouté

• Traitement sous-requête par sous-requête des grosses requêtes SQL : la durée d’un appel ne limite plus la taille de ce qui est traitable.
• Bandeau de progression visible depuis toutes les étapes du parcours, avec arrêt et reprise. Le traitement continue pendant que tu navigues.
• Reprise exacte après une interruption : seule la sous-requête interrompue est refaite, jamais celles déjà traitées.
• Les propositions déjà trouvées sont consultables même si le traitement n’est pas terminé.
• Un traitement retrouvé après un rechargement de page ne redémarre jamais tout seul : il attend ton clic, car chaque sous-requête a un coût.

Ajouté

• Vérification automatique de chaque réécriture proposée par l’IA : colonnes de sortie identiques (nombre, noms et ordre), texte SQL complet, aucun défaut introduit.
• En cas d’échec, la critique est renvoyée à l’IA pour correction (jusqu’à 2 fois). Rien ne quitte la confidentialité : la critique parle en noms masqués, aucun nom réel de ta base ne repart.
• Une proposition qui échoue encore après correction est abandonnée, et l’explication te le dit.
• L’IA est autorisée à être plus ambitieuse là où l’équivalence est vérifiable (fusionner des sous-requêtes réévaluées, factoriser des branches identiques), et reste prudente là où elle ne l’est pas.
• Les contrôles passés sont affichés sous chaque proposition.

Ajouté

• Le script de validation mesure les deux requêtes : durée, temps CPU et données réellement lues (la mesure la plus fiable, car elle ne dépend pas du cache du serveur).
• Un code compact à recopier du script vers l’app (« Reporter ta mesure ») : il ne contient que des compteurs, aucune donnée métier. Un code abîmé ou incomplet est refusé plutôt que deviné.
• La mesure remplace l’estimation partout : le tableau « Détail par optimisation » affiche alors le gain réel au lieu d’un ordre de grandeur.
• Une réécriture dont le verdict n’est pas IDENTIQUE ne se voit créditer aucun gain, et l’écart est affiché en clair.

Corrigé

• Le script échouait au lieu de répondre DIFFERENT quand la réécriture renvoyait un nombre de colonnes différent.
• Dans le tableau de mesure, un écart de lignes ou de colonnes ne se lit plus comme un gain : c’est précisément ce qui rend une réécriture invalide.

Modifié

• Le filtre par impact est maintenant unique pour tout le rapport : posé sur une étape, il vaut encore sur les suivantes et sur l’étape Générer. Le filtre par type, lui, reste propre à chaque page (ses catégories changent d’une page à l’autre).
• Le fil des étapes indique le nombre d’optimisations correspondant au filtre sur chaque étape, pour aller droit là où il y a du travail.
• Quand un filtre vient d’une autre page, le bandeau le dit (« hérité de l’étape Alléger ») : une page qui n’affiche plus que 2 cartes sur 12 ne peut plus passer pour vide ou cassée.
• Une liste vidée par le filtre affiche un message explicite avec le nombre d’optimisations sans le filtre, au lieu du « rien à traiter » habituel.
• Le filtre est inscrit dans l’adresse de la page : il survit au rechargement et le lien est partageable.

Corrigé

• Lisibilité du compteur « 0 » dans le fil des étapes, trop pâle sur fond sombre.

Ajouté

• Filtres par impact sur les 5 pages d’étape : une puce par axe (Taille, Pic refresh, Visuels, Extraction) à trois états, cumulables entre elles et avec le filtre par type existant. Un bandeau récapitule les filtres actifs et affiche « X sur Y optimisations ».
• Le composant de filtrage est désormais partagé avec le tableau de l’étape Générer : le filtrage se comporte et se lit exactement pareil aux deux endroits.

Ajouté

• Impact sur les 4 axes directement sur les cartes des 5 étapes d’optimisation : des pastilles au-dessus de chaque carte (taille, pic d’actualisation, visuels, extraction), avec les mêmes niveaux et les mêmes mots que le tableau de l’étape Générer.
• Nouvelle catégorie « Mise en cache » : le retrait d’un Table.Buffer est chiffré comme le levier majeur qu’il est (forte baisse du pic mémoire ET extraction plus courte, puisque le repli vers la source revient).
• Quand une optimisation est neutre sur les 4 axes (réglages de format, tri, résumé), c’est écrit : « aucun effet sur les 4 axes, donc sans risque ». Et quand le remède dépend de ton choix (par exemple une forte cardinalité, qui se traite au cas par cas), aucun impact n’est affiché plutôt qu’un chiffre inventé.

Corrigé

• Carte « Vitesse & durée » de l’étape Générer : « Extraction plus rapide » et « Actualisation plus longue » se contredisaient visuellement, car « Actualisation » n’était pas un axe mais une notion introduite sans être définie. La carte affiche désormais les mêmes axes que le tableau (vitesse des visuels, durée de la phase d’extraction), avec le décompte des optimisations qui améliorent et qui dégradent chacun, et une explication des deux phases d’une actualisation.
• Les déports sont présentés comme un transfert entre les deux phases, et non comme un pur coût : un coût sur l’extraction qui va de pair avec un gain sur le pic mémoire n’est pas une contradiction, et c’est maintenant expliqué.
• Sur les pastilles, plus de flèches : « ↓ » signifiait « la quantité baisse » sur les axes mémoire mais « la durée baisse » sur les axes de vitesse. La couleur et les mots suffisent et ne peuvent pas se lire à l’envers. Un montant n’est affiché que lorsqu’il est non ambigu (le détail chiffré reste dans l’infobulle et dans le tableau).

Ajouté

• Famille « Requête source » dans le tableau des 4 axes : une ligne par réécriture SQL embarquée, plus une ligne pour le réglage global « Optimisation des requêtes ». Le tableau couvre maintenant les 10 familles appliquées à la génération (il en couvrait 8).
• Décocher une réécriture SQL depuis le tableau l’exclut de la génération sans perdre le SQL : la ligne reste visible et re-cochable. Le récapitulatif « Requêtes embarquées » et la carte d’impact globale reflètent cette exclusion.

Corrigé

• Couleur des coûts : en thème clair elle était quasi noire (impossible de distinguer un coût d’un texte ordinaire), et la transparence des lignes décochées la faisait paraître marron - d’où deux couleurs apparentes pour le même message. Les coûts utilisent désormais un ambre dédié, franc et lisible en clair comme en sombre.
• Un montant précédé de « + » (un coût, par exemple les colonnes ajoutées par une clé de substitution) pouvait s’afficher en vert lorsque le bilan global de la cellule était favorable. Chaque montant est maintenant coloré selon son propre signe : « + » en ambre, « - » en vert.
• Un même libellé (« forte baisse », « forte hausse »…) s’affichait en gris quand il accompagnait un chiffre, et en couleur quand il était seul. Il garde désormais toujours la couleur de son sens ; seule la taille du texte marque la hiérarchie.

Ajouté

• Filtres par axe cumulables à l’étape Générer : une puce par axe (Taille, Pic refresh, Visuels, Extraction) à trois états (peu importe / gains / coûts). Plusieurs filtres actifs se combinent : seules les optimisations qui satisfont tous les critères en même temps restent affichées, avec une phrase qui l’explique.
• Compteur « X sur Y optimisations (filtres actifs) », bouton « Tout réinitialiser », et message dédié quand aucune optimisation ne cumule les effets demandés (c’est une information, pas une erreur).

Corrigé

• Lisibilité du tableau : les textes de coût (« plus longue », « forte hausse »…) étaient presque invisibles en thème sombre, et les noms d’optimisations étaient tronqués trop tôt (« Calc… », « M… »). Les couleurs de coût s’adaptent désormais au thème et la colonne des noms est nettement plus large.

Ajouté

• Impact sur les 4 axes par optimisation : aux deux axes mémoire (taille au repos, pic d’actualisation) s’ajoutent la vitesse d’affichage des visuels et la durée d’extraction des données. Un tiret « – » signifie « aucun effet attendu », ce qui est aussi une information utile (l’optimisation est sans risque de ce côté).
• Tri par axe : chaque en-tête de colonne est cliquable (1er clic = plus gros gains d’abord, 2e clic = plus gros coûts d’abord), pour repérer d’un coup d’œil les leviers d’un axe précis.
• Les 8 familles d’optimisations sont désormais dans le tableau et cochables individuellement : suppressions, clés de substitution, déports, réécritures DAX, tables calculées converties, relations bidirectionnelles, changements de type et réglages déterministes. Une ligne décochée reste visible (et peut être recochée).
• Clés de substitution : le coût certain (colonnes entières ajoutées) et le gain potentiel (suppression de la clé texte remplacée, non automatique) sont affichés séparément et clairement étiquetés - le bénéfice principal de la conversion n’est plus invisible.

Corrigé

• Relancer l’analyse ne détruit plus le travail accumulé : traductions de déport (Power Query / SQL), déports cochés, conversions de tables calculées, réécritures DAX de l’IA, cases « include » du crossfiltrage et statuts (validé / ignoré) sont repris sur les constats équivalents.
• Garde-fou : si la formule d’origine d’un calcul a changé depuis la dernière analyse, sa traduction et sa réécriture ne sont PAS réutilisées (elles seraient périmées et donneraient de faux résultats) et son statut repart à « détecté » pour une re-validation consciente.
• Le bouton « Relancer l’analyse » indique désormais que le travail est conservé, et le message de fin précise combien d’optimisations ont été reprises.

Ajouté

• Tableau « Détail par optimisation » : les déports sont désormais cochables directement dans le tableau (avec le chemin : à la source SQL, en Power Query, ou par fusion), avec filtre « Déports » dédié. La carte d’impact globale se recalcule en direct quand tu en coches ou décoches un.

Ajouté

• Tableau « Détail par optimisation » à l’étape Générer : coche/décoche unitaire des suppressions et des clés de substitution, avec pour chaque ligne son effet propre sur la taille du modèle (exact) et le sens/magnitude de son effet sur le pic d’actualisation. La carte d’impact globale reste la référence du pic combiné exact (les recalculs se chevauchent, l’effet propre ne s’additionne pas au centime). Tri par impact et filtre par type.

Modifié

• Carte « Impact estimé de ta sélection » (étape Générer) : l’effet sur la vitesse n’utilise plus de flèches ambiguës mais des libellés explicites (« plus rapide » / « durée plus longue ») avec la métrique concernée (affichage des visuels, chargement des données, durée d’actualisation) et une légende « plus rapide = durée plus courte ».

Ajouté

• Indicateur « Complétude des mesures » en tête de l’étape Mesurer : X/4 mesures fournies, barre de progression, et chaque ligne cliquable amène à la carte pour fournir la mesure manquante - pour t’inciter à fournir ce qui rend les estimations plus fidèles.

Modifié

• Étape Mesurer : les cartes qui demandent une action (pack de mesure, mesure d’actualisation, rapports connectés) sont regroupées en haut ; les résultats (contexte, tables, colonnes, clés lourdes, simulateur) suivent.
• Mesure du vrai pic mémoire : seule la méthode PowerShell est conservée (la plus fiable et sans surveillance) ; la méthode Gestionnaire des tâches, redondante, a été retirée.

Modifié

• Étape Mesurer : nouvelle mise en page équilibrée (pack de mesure + contexte sur 2 colonnes, Tables et Colonnes côte à côte, Simulateur et mesure réelle en pleine largeur) au lieu d’une colonne surchargée face à une carte isolée.

Modifié

• Étape Mesurer : suppression de la carte « Pic mémoire à l’actualisation (estimation) », trompeuse (elle ignorait le recalcul VertiPaq). L’estimation du pic est désormais portée uniquement par le Simulateur d’actualisation (toutes les phases) et par l’avant / après de l’étape Générer (recalé sur ta mesure réelle si tu l’as saisie).

Ajouté

• Recalage sur mesure réelle : à l’étape Mesurer (guide PowerShell), un champ permet d’enregistrer ton pic mémoire réellement mesuré. L’avant / après de l’étape Générer est alors recalé dessus, avec la mention « estimation recalée sur ton pic réel mesuré ».

Modifié

• Estimation du pic d’actualisation moins optimiste : le nombre de recalculs lourds tenus en même temps suit le réglage « évaluations simultanées » de Power BI (moitié du réglage, entre 3 et 6) au lieu d’être fixé à 3. Sur les très gros modèles, l’estimation ne sous-évalue plus le pic d’un cran - le garde-fou alerte plus justement.

Ajouté

• Étape Objectif : bloc « Suggestion d’après tes mesures » - les axes les plus payants sont mis en avant avec leur justification chiffrée (Go récupérables, pic au-dessus du budget), avec un bouton « Suivre la suggestion ». Les arbitrages sont affichés honnêtement (alléger le modèle peut augmenter le pic d’actualisation).
• Étape Générer : carte « Impact estimé de ta sélection » - delta de taille du modèle (suppressions moins colonnes ajoutées par les clés de substitution), pic d’actualisation avant → après avec verdict, part du pic due aux jointures des clés de substitution, et sens attendu sur la vitesse des visuels et de l’extraction.
• Garde-fou budget mémoire : si la sélection augmente le pic estimé au-delà du budget du poste (~60 % de la RAM), une alerte s’affiche avant le bouton Générer, avec les leviers concrets (décocher des clés de substitution, réduire le parallélisme d’actualisation).

Ajouté

• Moteur d’impact signé : chaque axe (taille au repos, pic d’actualisation) peut être positif OU négatif selon la sélection. Les suppressions retirent des octets mesurés ; les déports allègent le recalcul ; les clés de substitution ajoutent leur coût réel (jointure de la dimension pendant l’actualisation des faits + colonnes entières ajoutées).
• Simulation avant / après sur la sélection exacte : le pic d’actualisation est recalculé avec précisément les optimisations cochées (et plus seulement des scénarios théoriques « tout ou rien »), avec verdict contre le budget mémoire du poste.

Modifié

• Parcours inversé : « Mesurer » devient l’étape 1 et « Objectif » l’étape 2. Un bandeau explique la logique (on mesure d’abord, on choisit sa cible ensuite) ; passer la mesure reste possible, l’outil fonctionne alors avec des estimations.
• Pack de mesure en 2 blocs : bloc A « essentiel » (mémoire par colonne + lignes par table, requêtes légères sans balayage des données) et bloc B « affinage » optionnel (cardinalité, requêtes lourdes découpées). Fini les 3 zones d’import séparées : un seul champ de collage accepte tous les résultats, dans n’importe quel ordre.
• Les imports de mesure se cumulent désormais : coller le bloc A après le bloc B (ou l’inverse, ou en plusieurs fois) ne perd plus jamais les valeurs déjà importées.

Modifié

• Étape Objectif : 4 objectifs clairs alignés sur des axes mesurables - Alléger le modèle, Fiabiliser l’actualisation (pic mémoire au refresh, nouvel axe), Accélérer les visuels, Accélérer l’extraction. Les optimisations qui pèsent sur le pic de mémoire à l’actualisation (tables mises en cache, repli de requête cassé, colonnes calculées recalculées au refresh) sont désormais rattachées à l’objectif « Fiabiliser l’actualisation ».
• La cohérence des formules n’est plus un objectif à sélectionner : les alertes restent affichées en permanence (carte « Cohérence des formules »), quel que soit l’objectif choisi.
• « Rechercher / remplacer du texte » quitte la liste des objectifs : l’outil reste accessible dans l’annexe « Outils ».

Corrigé

• Rapprochement de tables (déport par fusion) : plus d’échec « Nous n’avons pas trouvé le champ … » quand le calcul dépend d’une colonne au nom contenant des espaces/caractères spéciaux restée en DAX. La dépendance est de nouveau détectée et le rapprochement correctement écarté.

Corrigé

• Déplacement de calculs / rapprochement de tables : plus d’erreur « Le type de la valeur ne correspond pas à celui de la colonne » quand une colonne générée renvoie une valeur vide sur certaines (ou toutes) les lignes. Les colonnes générées acceptent désormais les valeurs vides.

Corrigé

• Conversion des clés de relation en texte : plus de plantage « impossible de convertir la valeur … en type Text » quand une clé déclarée comme du texte contient en réalité des nombres. La valeur est convertie en texte avant comparaison, des deux côtés de la relation.

Corrigé

• Rapprochement de tables (déport par fusion) : plus de blocage « colonne introuvable » à l’actualisation lorsqu’une table combine une clé de substitution et des déplacements de calculs. Un rapprochement qui s’appuierait sur une colonne finalement non déplacée est automatiquement écarté ; les rapprochements sur les tables non concernées sont conservés.

Corrigé

• Déplacement de calculs vers la source de données : plus de blocage « colonne introuvable » à l’actualisation. Une colonne calculée qui dépend d’une autre colonne calculée n’est plus envoyée à la base de données (où la colonne dont elle dépend n’existe pas) ; elle reste inchangée ou passe par Power Query.

Corrigé

• Conversion des clés de relation en texte : plus de blocage « une référence cyclique a été détectée » à l’actualisation. Les conversions qui créeraient une boucle (table reliée à elle-même, chaînes de tables qui bouclent) sont détectées et écartées automatiquement, avec la raison affichée ; les autres sont converties. Le fichier généré s’actualise toujours.

Corrigé

• Conversion des clés de relation en texte : l’actualisation ne bloque plus (« Le nom … est défini plusieurs fois ») lorsqu’une table est reliée à plusieurs autres par des clés en texte. Les étapes de calcul générées portent maintenant des noms uniques.

Corrigé

• Conversion des clés de relation en texte : le fichier Power BI généré ne refuse plus de s’ouvrir (erreur « mise en retrait non valide »). La nouvelle colonne de clé numérique est désormais insérée à un emplacement valide dans le fichier du modèle.

Corrigé

• Import d’un rapport connecté : le fichier des mesures définies dans le rapport (reportExtensions.json) est désormais conservé à l’envoi. Une colonne consommée uniquement par une de ces mesures n’est plus proposée à la suppression.
• Action requise : re-connecte les rapports connectés concernés (leurs champs utilisés sont figés au moment de l’ajout).

Ajouté

• Import multiple de rapports connectés : sélectionne plusieurs fichiers (.pbix, .zip, .rdl) en une fois. Progression affichée, bilan récapitulatif, et un échec n’arrête pas le lot.

Ajouté

• Conversion automatique des clés de relation texte en clés entières de substitution (étape « Restructurer ») : opt-in par relation, avec la cardinalité pour prioriser.
• Clés composées (COMBINEVALUES, concaténations) gérées : la substitution est bâtie directement sur le tuple des colonnes source, ce qui reproduit exactement l’appariement d’origine.
• L’appariement est reproduit à l’identique (insensible à la casse, toutes les lignes de faits conservées) ; les colonnes texte d’origine sont conservées et masquées.
• Rappel appuyé : « hors fidélité garantie » - lancer le contrôle de fidélité (et sa version stricte) après génération.

Corrigé

• Une colonne utilisée uniquement par une mesure définie dans le rapport (report-level measure) n’est plus proposée à la suppression : l’outil lit maintenant la formule de ces mesures et en suit les colonnes.

Ajouté

• Rapports connectés : rappel qu’un rapport connecté avant cette version doit être re-ajouté pour que ses mesures internes soient prises en compte (ses champs sont figés au moment de l’ajout).

Corrigé

• Optimisation « montant en virgule flottante » : l’actualisation ne plante plus quand la source est du texte avec un point décimal. L’outil ne réécrit plus le type dans Power Query - il change seulement le type de stockage du modèle (la valeur étant déjà un nombre valide, il n’y a rien à reconvertir).
• Bonus : les colonnes montant sans étape de type explicite en Power Query, jusque-là laissées de côté, sont désormais traitées aussi.

Modifié

• Les données ne se rechargent plus toutes seules quand tu reviens sur l’onglet du navigateur (elles se rafraîchissent sur action, ou par un rechargement manuel de la page) : c’était la principale cause du transfert réseau.
• La liste des optimisations n’est plus relue tant qu’elle est récente (5 min au lieu de 30 s).
• Le chargement d’un rapport ne lit plus les optimisations « colonne/mesure inutilisée », qui étaient récupérées puis ignorées (elles sont gérées par l’écran de nettoyage) : autant de transfert en moins.

Corrigé

• Les causes d’un écart décrivent le fichier réellement généré, plus les cases cochées depuis : une optimisation présente dans le .pbip mais désactivée après coup est de nouveau proposée comme cause (elle est bel et bien dans le fichier testé).
• Un avertissement signale quand les réglages ont changé depuis la génération du fichier testé, avec le détail par famille, et invite à régénérer.

Ajouté

• Dépendances entre colonnes : quand une colonne en écart lit une colonne déportée dans sa formule, ce déport est proposé comme cause - même si la colonne en écart n’est pas déportée elle-même.
• Les suspects dont la colonne lue ressort identique avant/après sont écartés dans un bloc replié (et non masqués : le contrôle compare des totaux, qui ne voient pas des valeurs justes posées sur les mauvaises lignes).
• Version stricte de la requête de contrôle (optionnelle) : elle compte les combinaisons entre chaque colonne et une colonne source de sa table, ce qui rend visible une valeur qui change de ligne - le mode de défaillance typique d’un déport par fusion. Plus lente, à réserver au doute.

Ajouté

• Tests automatiques sur la page d’analyse : ils vérifient qu’aucun bouton « Générer le .pbip » ne réapparaît hors de la page Générer, et surtout que le récap « Ce qui sera appliqué » annonce bien CHAQUE famille d’optimisations - un oubli comme celui des réglages de format serait maintenant signalé tout seul.

Modifié

• La barre horizontale collée en bas de page (récap + bouton « Générer le .pbip ») est supprimée : le bouton se trouve sur la page « Générer », et la page gagne l’espace correspondant.
• Récap « Ce qui sera appliqué » : toutes les familles d’optimisations y figurent désormais - réglages de format/résumé/tri, réécritures DAX, relations bidirectionnelles, tables calculées converties, changements de type et optimisation des requêtes - en plus des suppressions, déports et requêtes embarquées déjà présents.

Corrigé

• Changements de type (datetime → date) : l’actualisation échouait (« Le type de la valeur ne correspond pas à celui de la colonne ») sur les sources livrant leurs dates en texte. Le type de lecture d’origine est désormais préservé et l’heure est coupée dans une étape ajoutée après.
• L’outil s’abstient de couper l’heure d’une colonne qui n’est pas explicitement lue en « date et heure » dans Power Query, et l’explique dans le récap de génération.
• Déports par fusion : le type de la colonne copiée était déduit du format d’affichage avant d’examiner le calcul réel. Un format numérique resté sur une colonne de texte la typait en nombre (erreur à chaque ligne). L’ordre de confiance est aligné sur celui des autres déports - ce que le calcul produit prime, le format d’affichage ne sert qu’en dernier recours.

Ajouté

• Comparateur de fidélité : synthèse en tête indiquant, parmi les objets en écart, combien portent sur des tables non modifiées par l’outil (écart venant de la source) et combien sur des tables optimisées (à tester).

Modifié

• Un écart sur une table jamais touchée par une optimisation affiche un message affirmatif (« aucune transformation appliquée à cette table, l’écart vient d’un changement de la source entre les deux actualisations ») au lieu du message hésitant précédent.
• Un écart sur une table optimisée dont le suspect vient d’être désactivé invite explicitement à régénérer le .pbip puis à recontrôler.

Modifié

• Comparateur de fidélité : les écarts purement d’arrondi (calcul flottant non déterministe) sont ignorés et signalés à part (« N écarts négligeables ignorés »).
• Causes d’un écart : les déports différés (grosses tables au-dessus du seuil, laissés en DAX) ne sont plus listés comme suspects - ils ne sont pas appliqués.
• Ajout d’un rappel : pour une comparaison valable, actualiser les deux fichiers sur la même donnée source ; un écart sans optimisation active vient souvent d’une source qui a changé entre les deux actualisations.

Corrigé

• Le bouton « Générer le .pbip » est bloqué (« Enregistrement… ») tant qu’une désactivation d’optimisation à statut (déport, réécriture, conversion de table calculée) n’est pas enregistrée, pour que le fichier généré reflète toujours tes derniers choix.

Corrigé

• Page Générer : le groupe « Déports vers Power Query / SQL / fusion » disparaît bien du récap dès la désactivation (les déports étaient déjà correctement exclus de la génération - c’était un défaut d’affichage).

Corrigé

• Page Générer : le groupe « Déports vers Power Query / SQL / fusion » disparaît bien du récap quand on le désactive (en masse ou à l’unité).

Ajouté

• Page Générer : bouton « Tout désactiver » par groupe d’optimisations (même type) et « Désactiver » par optimisation unitaire, directement dans le récap « Détail des optimisations appliquées ».

Ajouté

• Contrôle de fidélité : pour une colonne calculée, l’outil lit sa formule, repère les tables qu’elle référence (RELATED / LOOKUPVALUE…) et, si l’une d’elles a été déportée, la propose comme cause (« Déports sur la table X, référencée par cette colonne calculée ») avec désactivation groupée.

Corrigé

• Sous un objet en écart, ajout d’un suspect au niveau table « Déports sur la table X (N colonnes) » qui couvre toutes les colonnes de la table et son nombre de lignes (cas d’une fusion ou d’une dépendance entre colonnes), avec « Désactiver » groupé. Fini le « aucune optimisation » sur une colonne d’une table pourtant déportée.

Ajouté

• Contrôle de fidélité : sous chaque objet en écart, la liste des optimisations qui pourraient en être la cause, chacune avec un bouton « Désactiver ». Seules les optimisations qui peuvent réellement changer une valeur sont listées (les optimisations sûres, comme la suppression de colonnes inutilisées, ne le sont jamais).
• Bandeau récapitulatif « X optimisation(s) désactivée(s) - régénère le .pbip puis relance le contrôle » pour boucler la vérification.

Ajouté

• Contrôle de fidélité : requête de repli « sans les mesures » (dépliable sous la requête principale), à utiliser quand une mesure a une erreur de calcul latente qui bloque la requête complète. Contrôle tables + colonnes uniquement, toujours exécutable.

Corrigé

• Requête de contrôle de fidélité : chaque valeur est protégée (IFERROR) - une mesure qui échoue à l’évaluation renvoie « #ERREUR » au lieu de faire échouer tout le contrôle. Tu obtiens enfin la signature de toutes les tables, colonnes et mesures évaluables.

Modifié

• Génération : le fichier .pbip à l’intérieur de l’archive .zip est renommé comme l’archive (ex. « MonRapport.optimized.2026-07-10_14-30.pbip »). Les dossiers .Report / .SemanticModel restent référencés correctement (le projet s’ouvre normalement dans Power BI).

Modifié

• Réécriture DAX / Power Query par IA : les commentaires existants sont conservés dans le résultat (l’IA les garde au plus près du code qu’ils annotaient).
• Réécriture SQL par IA : les commentaires sont préservés via des repères neutres (leur contenu reste masqué à l’IA, comme les noms et les valeurs), puis restaurés dans la requête optimisée.
• Carte « Confier la réécriture à un agent sans limite (requête lourde) » : le brief intègre la consigne de conserver les commentaires existants.

Ajouté

• Page d’erreur propre pour la zone rapport : message rassurant (tes données sont conservées), bouton « Réessayer » et lien « Retour à mes rapports », au lieu de la page blanche « Application error ».

Corrigé

• Page blanche (« Application error ») à l’ouverture d’un rapport neuf : la préparation de l’analyse des requêtes est désormais lancée au bon moment dans le rendu, ce qui supprime le plantage.

Ajouté

• Cloche de notifications dans l’en-tête (visible une fois connecté) : pastille du nombre de non-lues, panneau déroulant listant les notifications, marquage lu / tout lire, et clic pour ouvrir la page liée.
• Base technique pour notifier un utilisateur depuis le serveur (une notification = titre, texte, lien). Prête à être branchée sur les événements de l’app (ex. « ton analyse est terminée »). Option future : notifications système sur le téléphone (push).

Ajouté

• Score d’enjeu par requête sur la page Affiner : pastille de couleur (élevé / moyen / faible) + ligne « pourquoi » listant les facteurs dominants (ex. « 12 M lignes · repli cassé dès l’étape 2 · LIKE avec joker en tête »), avec la nature de l’enjeu (charge serveur, extraction / mémoire, ou les deux).
• Deux axes distincts dans le calcul : coût serveur (réduit par la réécriture SQL) et coût extraction (réduit en préservant le repli). Utile car pousser le travail vers le serveur soulage ton PC mais charge le serveur - les deux comptent.

Modifié

• Le panneau des requêtes trie maintenant par enjeu décroissant (au lieu du seul volume) : tu attaques d’abord ce qui pèse vraiment sur le rafraîchissement et le serveur.

Modifié

• Étape Affiner : le panneau « Accélérer le chargement (requêtes) » - qui contient la réécriture SQL assistée par IA avec masquage des noms de serveur, base, table et champ - passe désormais en tête de page lorsque l’objectif « Accélérer l’extraction des données » est sélectionné, au lieu d’être sous la liste des constats DAX.
• Le compteur « traitées » de l’étape Affiner inclut maintenant les requêtes SQL optimisables : une requête est comptée comme traitée quand sa réécriture est embarquée.

Ajouté

• Une pastille de filtre « Requêtes SQL » aux côtés des types de constats de l’étape Affiner ; un clic fait défiler jusqu’au panneau des requêtes.

Ajouté

• Sur la page Outils, sous la requête de contrôle de fidélité : deux zones pour coller le résultat exécuté sur l’original et sur l’optimisé. Le comparateur affiche « fidélité confirmée » si tout est identique, ou la liste des objets en écart (avec, pour chaque, l’agrégat concerné et les deux valeurs) et le rappel de la marche à suivre : retirer l’optimisation qui touche l’objet, re-générer, recoller.
• Parsing tolérant : tabulation, point-virgule ou virgule, en-tête optionnel, noms d’objets entre guillemets - de quoi coller directement ce qui sort de la vue Requête DAX ou de DAX Studio.

Modifié

• Lors de la conversion d’une table calculée en Power Query, l’IA connaît maintenant l’état de chaque colonne référencée (source / calculée déportée = disponible, ou calculée non déportée = à reproduire, avec sa formule DAX) et le fait qu’une table calculée référencée sera elle-même convertie. Elle peut donc traiter des tables qu’elle refusait faute de pouvoir résoudre leurs filtres.
• Garde-fous renforcés dans les consignes : un CONCATENATEX sans ordre explicite (ordre non garanti) n’est traduit que si l’ordre est reproductible à l’identique, sinon la conversion est refusée - la fidélité prime.

Ajouté

• Carte « Détail des optimisations appliquées » : avant génération, le plan groupé par nature avec la liste des objets concernés (dépliable) ; après génération, la liste réelle des optimisations appliquées, plus celles non appliquées avec leur raison.
• Carte « À réaliser manuellement dans Power BI (après génération) » : chaque étape manuelle avec son intitulé, l’objet concerné, son impact et son explication - de quoi tout traiter sans quitter la page.

Modifié

• « Changements de type » (date-heure → date, flottant → décimal) se règle désormais sur la page Alléger, où vivent les colonnes concernées.
• « Optimiser les requêtes » (réécritures à résultat identique) se règle désormais sur la page Affiner, auprès du panneau des requêtes.
• La page Générer affiche l’état de ces deux options en lecture seule (activé / désactivé) avec un lien vers la page correspondante, au lieu des cases à cocher.

Ajouté

• Dans le guide « Mesurer le VRAI pic mémoire » (page Mémoire), une méthode « script PowerShell » avec bouton « Copier » : coller dans PowerShell, lancer l’actualisation, lire la valeur « PIC » à l’écran. Aucune installation, aucun droit administrateur, aucun fichier écrit sur le disque (évite les soucis de Bureau redirigé sur un poste pro). La méthode « Gestionnaire des tâches » (visuelle) reste disponible en alternative.

Modifié

• La section « Mémoire d’actualisation mesurée » distingue explicitement les deux phases (extraction Power Query vs chargement/recalcul VertiPaq) et précise que le chiffre issu des diagnostics ne concerne que l’extraction - avec un encart d’avertissement pour éviter la comparaison trompeuse avec l’estimation du simulateur (qui porte, elle, sur le recalcul).

Ajouté

• Guide pas-à-pas pour mesurer le vrai pic mémoire (phase de chargement/recalcul) avec le Gestionnaire des tâches : suivre le processus « Microsoft SQL Server Analysis Services » (msmdsrv.exe) pendant une actualisation, ou à défaut la mémoire « Utilisée » totale. C’est ce chiffre qui se compare à l’estimation du simulateur.

Corrigé

• Les colonnes et tables des tables de dates auto-générées par Power BI (noms « LocalDateTable… » / « DateTableTemplate… », cachées) ne sont plus comptées comme colonnes/tables calculées à déporter, convertir ou dont il faut affiner la granularité. Vérifié sur un modèle réel : de 60 déports proposés à tort à 0, et une seule recommandation pertinente (« désactiver Date/heure automatique »).

Ajouté

• Déport coordonné des clés de relation : une clé calculée n’est déportée que si, pour chaque relation dont elle fait partie, l’autre bout part lui aussi « à la source » (SQL) - ou est déjà une colonne source en texte - avec le même type forcé. Les deux clés produisent alors des valeurs identiques, la relation reste intacte. Toute clé qui ne remplit pas ces conditions reste en DAX, exactement comme dans l’original.

Corrigé

• Une clé de relation n’est plus jamais déportée en Power Query ni par fusion (seul le déport coordonné « à la source » préserve la relation), et une clé bâtie sur un nombre ou une date reste en DAX (leur mise en forme texte diffère entre DAX et SQL). Sur le modèle réel : 35 clés de relation calculées, dont 4 déportées en toute sécurité et 31 conservées en DAX, avec zéro relation cassée (dont celle entre « Nomenclature Technique par Site affecté » et « Commandes Matières et composants en cours »).

Corrigé

• Les calculs déportés en Power Query ne peuvent référencer que des colonnes sources, des colonnes déportées en SQL (présentes dans la requête native) ou d’autres colonnes déportées de la même table - une référence vers une colonne restée en DAX disqualifie le déport, de proche en proche (en écarter une peut en invalider une autre).
• Les restes de calcul des fusions mixtes sont soumis à la même règle, avec une contrainte de plus : au moment de la jointure, les déports Power Query de la table n’existent pas encore - seules les colonnes sources, les déports SQL et le champ d’appoint de la fusion sont disponibles.
• Sur le modèle réel : 7 déports Power Query et 4 fusions mixtes écartés avec la raison précise (la colonne référencée est nommée), le reste du plan est conservé.

Corrigé

• Le type d’une colonne déportée en SQL est déduit dans l’ordre : type déclaré, expression manifestement texte (CONCAT, concaténations, fonctions texte), format d’affichage, agrégation par défaut, littéraux de résultat (CASE … THEN 1 ELSE 0 → nombre entier). Si rien ne permet de conclure, la colonne bascule sur le déport Power Query (dont la traduction porte plus d’indices) au lieu de recevoir « texte » au hasard.
• Même chaîne pour les fusions : format d’affichage, inférence sur le reste de calcul traduit (if … then 1 else 0 → nombre), type de la colonne rapatriée (y compris celui assigné par un déport de la même génération). Type indéterminable → la colonne reste en DAX, avec explication.
• L’inférence du déport Power Query reconnaît désormais les colonnes « check » (if … then 1 else 0) comme numériques.
• Vérifié sur le modèle réel : 57 colonnes à type inconnu reçoivent un type numérique/date correct (au lieu de « texte »), 3 restent prudemment en DAX.

Corrigé

• Chaque jointure de fusion développe ses colonnes sous un nom d’appoint qui lui est propre (suffixe « (2) » à partir de la deuxième jointure rapatriant la même colonne), et chaque colonne copiée lit le champ de SA jointure.
• Cas particulier des fusions « mixtes » (avec un reste de calcul traduit) : leur nom d’appoint doit rester exact - il est réservé en priorité, et une collision entre deux mixtes fait refuser proprement la fusion de la table (colonnes laissées en DAX) au lieu de produire un fichier cassé.

Corrigé

• La génération vérifie chaque traduction (SQL, Power Query, fusion, conversion de table) avant de l’embarquer : un jeton d’anonymisation résiduel la disqualifie avec une explication, et la colonne reste en DAX (résultat inchangé). Trois colonnes de ce type sont concernées sur les traductions existantes.
• Le masquage des noms envoyés à l’IA traite désormais les noms entre crochets en premier : un nom de colonne court (« Date ») ne peut plus être remplacé à l’intérieur d’un nom long qui commence pareil, ce qui créait des jetons hybrides.
• Le dé-masquage des réponses de l’IA se fait en une seule passe : un remplacement ne peut plus réintroduire un jeton déjà traité.

Corrigé

• Le retrait du « ; » final et des commentaires de fin de requête ne traverse plus jamais un littéral réel : il recule segment par segment (blancs réels, « ; » réels, commentaires entiers) au lieu de s’appuyer sur une version masquée du texte où les littéraux ressemblaient à des espaces.

Corrigé

• Chaque fusion est validée avant d’être injectée : ses clés et sa colonne cherchée doivent exister dans les requêtes concernées - colonne source, ou colonne déportée dans la même génération (SQL, Power Query, autre fusion, table convertie). Une fusion irréalisable est refusée avec la raison précise et la colonne reste en DAX (résultat inchangé).
• Le refus d’une fusion invalide automatiquement celles qui comptaient dessus (calcul de proche en proche), et côté table de départ seules les colonnes sources ou déportées en SQL comptent - la jointure s’exécute avant les ajouts Power Query.
• Les tables dont la requête SQL n’est pas enveloppable (plusieurs instructions, DECLARE…) sont écartées du déport SQL dès la planification : leurs colonnes basculent sur le déport Power Query classique au lieu d’être perdues, et les fusions ne comptent plus sur des colonnes qui n’arriveraient jamais.

Corrigé

• L’enveloppe SQL nomme désormais la sous-requête « src », conformément à ce qui est annoncé à l’IA de traduction - ses expressions qualifiées (src.Colonne) retrouvent leurs colonnes.
• Les requêtes d’origine qui commencent par WITH (une « CTE ») sont enveloppées correctement : le WITH est hissé au-dessus de la sous-requête au lieu d’y être enfermé (interdit par SQL Server).
• Une colonne déportée qui en utilise une autre est calculée dans un étage de sous-requête supplémentaire (imbrication automatique par niveau de dépendance) au lieu d’être introuvable au même niveau.
• Les noms de colonnes à espace ou caractère spécial oubliés sans crochets par l’IA ([UOMBuy SAP]) sont crochetés automatiquement à la génération, hors textes entre apostrophes.
• Les requêtes non enveloppables (plusieurs instructions, DECLARE…) sont refusées proprement : les colonnes concernées restent en DAX et la génération l’explique, au lieu de produire un fichier cassé.

Ajouté

• Titre d’onglet dédié pour les pages Contact, Connexion et Inscription : plus facile de s’y retrouver quand plusieurs onglets du site sont ouverts.

Corrigé

• Le nom du site n’apparaît plus qu’une seule fois dans le titre de l’onglet du navigateur, sur toutes les pages.
• La page Politique de confidentialité affichait en plus un nom technique interne dans son titre ; elle affiche désormais « Politique de confidentialité | PBI Optimizer ».

Corrigé

• Chaque réécriture supplémentaire de la requête d’une même table utilise désormais des noms d’étapes uniques (suffixe automatique : __PBIoptStable2, __PBIoptBase2…). Cela couvre aussi le re-téléversement d’un fichier déjà optimisé, qui contenait déjà ces étapes.

Ajouté

• Barre d’étapes en haut de page : Objectif → Mesurer → Nettoyer → Alléger → Restructurer → Affiner → Peaufiner → Générer, avec l’avancement en direct sur chaque pastille (reste à traiter, coche quand c’est fini) et un accès direct à la page Outils. Boutons Précédent/Suivant en bas de chaque page. L’adresse de la page retient l’étape ouverte (partageable).
• Page « Objectif » : choix des objectifs, résumé du diagnostic, prochaine action recommandée et alertes de cohérence, réunis sur un seul écran d’entrée.
• Page « Générer » : récapitulatif de ce qui sera appliqué, options, génération du .pbip et plan d’action au même endroit. La barre du bas devient un simple rappel compact avec un bouton vers cette page.

Modifié

• Les longues listes d’optimisations s’affichent par groupes de 20 cartes (bouton « Afficher les 20 suivantes ») au lieu de centaines d’un coup : c’était la cause principale des lenteurs d’affichage.
• Valider ou ignorer une optimisation est désormais instantané : l’interface se met à jour immédiatement sans re-télécharger toute la liste depuis le serveur (mise à jour « optimiste », annulée automatiquement en cas d’erreur).
• Les filtres par type d’optimisation sont des pastilles en tête de chaque étape (l’ancien rail latéral et son zoom sont remplacés par la navigation en pages).

Modifié

• Le résultat du décorticage de votre fichier est gardé en mémoire côté serveur (cache) et réutilisé par tous les affichages de la page : classement mémoire, simulateur d’actualisation, analyse des requêtes, colonnes supprimables, déports, fusions, contrôle de fidélité, etc. Sur un gros modèle, l’ouverture de la page et les actions passent de plusieurs dizaines de secondes à quelques secondes au premier affichage, puis deviennent quasi instantanées.
• Quand plusieurs affichages demandent le fichier au même moment, un seul téléchargement et un seul décorticage sont effectués puis partagés (dédoublonnage des demandes simultanées).

Corrigé

• À la génération, seules les colonnes RÉELLEMENT déportées (présentes dans une opération de déport) sont protégées de la suppression. Une colonne dont le déport Power Query est reporté par le seuil de taille redevient supprimable si elle est inutilisée - au lieu de rester une colonne calculée morte, exclue à la fois du déport et du nettoyage. Sur un gros modèle, cela retire plusieurs dizaines de colonnes du recalcul de fin d’actualisation.

Corrigé

• Le seuil de taille (qui reporte le déport d’une colonne sur une très grosse table) ne s’applique désormais qu’au déport Power Query, jamais au déport à la source SQL ni aux fusions - ceux-là sont calculés par le serveur ou par une jointure et s’appliquent quelle que soit la taille de la table. Résultat : ces déports comptent enfin comme « faits » (barre du bas, avancement des étapes, état des lieux du déport) au lieu d’apparaître à tort comme « à traiter ».

Modifié

• Guide « Comment mesurer » du panneau Mémoire réécrit avec les pièges réels balisés : activation des diagnostics via Fichier → Options si l’onglet Outils ne montre pas la case, fenêtre Power Query à laisser ouverte pendant l’actualisation, mesure à poursuivre jusqu’à l’erreur mémoire (c’est elle qu’on veut chiffrer), copie de la table entière via l’icône de grille, et nettoyage après import (diagnostics à désactiver). Le guide est désormais déplié par défaut.

Ajouté

• Nouveau panneau « Contrôle de fidélité des données » (onglet Outils) : une requête DAX prête à copier, couvrant uniquement les objets réellement utilisés (colonnes affichées, mesures, clés de relation) - COUNTROWS par table, COUNT/SUM/MIN/MAX pour les nombres, nombre de valeurs distinctes et somme des longueurs pour le texte, bornes pour les dates. Un guide en 3 étapes explique comment l’exécuter sur les deux fichiers et comparer.

Inclus

• 100 % déterministe (aucune IA, aucun coût) et exécuté chez toi : aucune donnée ne quitte ton poste. C’est le garde-fou qui accompagne les déports et conversions « hors fidélité garantie » : un écart sur une ligne pointe exactement l’objet à revérifier.

Ajouté

• Assistant « Convertir en requête Power Query » sur chaque carte de table calculée : bouton « Proposer la conversion (IA) » (la formule DAX de la table - DISTINCT, SUMMARIZE, FILTER… - devient une requête M qui référence les requêtes des autres tables), aperçu de la requête, explication et points de vigilance, puis case « Convertir à la génération ».
• Triple garde-fou déterministe : la requête proposée est refusée si elle utilise une fonction M inconnue ou Table.Buffer (la cause historique des saturations mémoire), et la table convertie est projetée STRICTEMENT sur ses colonnes actuelles - toute dérive de schéma fait échouer l’actualisation explicitement au lieu de charger des données fausses.
• Dans le fichier généré : la partition calculée devient une vraie requête (bascule « = calculated » → « = m »), et les colonnes héritées de la formule deviennent des colonnes sources normales - relations, mesures et visuels qui les utilisent restent intacts.

Inclus

• Comme les déports, la conversion est « hors fidélité garantie » : après actualisation, compare le nombre de lignes et quelques valeurs avec la version d’origine (doublons, vides, casse et tri sont les écarts classiques, listés par l’IA dans ses points de vigilance).

Ajouté

• Case « Déporter par fusion à la génération » sur chaque colonne à recette de fusion applicable : la jointure (clés déduites des relations du modèle ou de l’expression) est injectée dans le .pbip généré, partagée entre les colonnes qui lisent la même table, et la table jointe est réduite à ses colonnes utiles puis dédupliquée sur ses clés - le nombre de lignes de ta table ne peut pas changer. Cas mixte : le reste du calcul est traduit une fois en Power Query (IA).
• « Tout déporter les fusions » dans la carte Déport : aperçu gratuit (fusions pures gratuites / mixtes avec coût IA estimé / sans recette), exécution par lots avec reprise, récapitulatif détaillé.
• L’état des lieux du poste de commande et tous les compteurs (barre du bas, étapes) comptent désormais les fusions cochées - et, correction au passage, les déports « SQL seul » qui n’étaient pas comptés comme traités dans l’interface.

Corrigé

• La recette de fusion affichée (à coller à la main) référençait la table jointe comme un texte au lieu d’une requête : le collage échouait dans l’éditeur avancé. Corrigé (référence # « Table »).

Inclus

• Moteur validé sur un modèle réel de 85 tables : 26 fusions pures injectées sur 8 tables en une génération, fichier re-parsé intègre (toutes les colonnes conservées, converties en colonnes sourcées). Comme tout déport, compare quelques valeurs après actualisation (clés en double, valeurs vides, casse).

Modifié

• « Tout déporter en Power Query » devient un déport en masse à deux voies : SQL à la source d’abord (tables à requête SQL native unique), Power Query en repli. Chaque proposition SQL passe les mêmes gardes de sécurité que le déport individuel (jamais d’instruction, de commentaire ou de point-virgule).
• Repêchage : une colonne dont la traduction Power Query avait été refusée est retentée par la voie SQL si sa table y est éligible - l’écran de confirmation en tient compte dans ses compteurs et son estimation de coût.

Ajouté

• Carte « Simulateur d’actualisation » dans le panneau Mémoire : renseigne la RAM de ton poste et tes réglages Desktop (évaluations simultanées, Mo par évaluation), et obtiens le verdict de chaque phase - chargement des données, transaction (double copie du modèle), recalcul final à l’enregistrement (la phase qui produit « La mémoire est insuffisante… »). Fourchettes calibrées sur un cas réel d’échec.
• Scénarios « Et si… » cumulatifs et chiffrés : suppression des colonnes inutilisées → déport facile (SQL / Power Query) → déport des fusions (RELATED / LOOKUPVALUE) → conversion des tables calculées. Chaque palier recalcule le pic et son verdict : tu vois exactement quelles actions rendent l’actualisation possible sur ta machine.
• Liste des « leviers » : les tables qui pèsent au recalcul, avec leur poids re-balayé, leurs colonnes calculées (dont full-scan), et combien sont déportables facilement ou par fusion.

Inclus

• La simulation est entièrement déterministe (aucune IA, aucun coût) et se calcule depuis la structure du modèle, la volumétrie et la mémoire réelle importées. Elle raisonne prudemment : une table reste re-balayée tant qu’il lui reste une seule colonne calculée.

Corrigé

• La colonne latérale de droite (contexte et imports) et le bandeau d’étapes de gauche ont leur propre zone de défilement : sa hauteur maximale tenait compte du haut de l’écran mais pas de la barre d’actions fixée en bas, si bien que le dernier bouton (import des compteurs de performances / mémoire réelle) passait sous cette barre. La hauteur retranche désormais la hauteur réelle de la barre, laissant le bouton toujours cliquable.

Modifié

• Palette sombre réaccordée à la teinte bleu ardoise de la marque : fonds, cartes, boutons, bordures et couleurs de graphiques portent à nouveau la même tonalité que le mode clair. Les couleurs de sens (vert des gains, ambre des avertissements, rouge des erreurs) restent inchangées. Vérifié visuellement dans les deux modes.

Ajouté

• Bouton menu (burger) dans l’en-tête sur mobile et tablette : panneau latéral avec Fonctionnalités, Comment ça marche, Contact, l’accès à ton espace (ou l’espace admin) quand tu es connecté, et le sélecteur de thème clair/sombre (lui aussi inaccessible sur mobile jusqu’ici).

Corrigé

• Entre 768 et 1024 px, les liens de l’en-tête se disputaient la place avec les boutons et « Comment ça marche » s’étalait sur trois lignes : la barre de liens ne s’affiche plus qu’au-delà de 1024 px, le menu burger prenant le relais en dessous.

Modifié

• Les 8 cartes « Ce que PBI Optimizer fait » et les 4 étapes « Comment ça marche » sont réécrites en langage clair : « rupture du repli de requête » expliquée (la requête cesse d’être exécutée par la base et bascule sur ton poste), « relations à double sens repassées en sens unique », « colonnes inutilisées » plutôt que « mortes », « volumétrie » définie (tailles réelles de tables), « passage de relais à un assistant externe » plutôt que « handoff ».
• La carte « Alléger la mémoire » mentionne désormais le déport à la source (le calcul confié directement à ta base de données SQL), disponible depuis la v1.40.0.

Ajouté

• Mini-guide d’accueil sur l’espace de travail tant qu’aucun rapport n’est déposé : les 4 étapes du parcours en langage clair (dépôt du .pbip avec données restées sur ta machine, choix de l’objectif, validation de chaque proposition, téléchargement du .pbip optimisé et du plan d’action), plus le rappel de la conservation 7 jours en Europe. Il s’efface dès le premier rapport analysé.

Modifié

• Sous chaque proposition IA non validée, un encart « Étape restante » précise que la réécriture ne sera appliquée au .pbip généré qu’après un clic sur « Valider » (et qu’« Ignorer » l’écarte). L’encart disparaît une fois la carte validée ou la colonne déportée.
• Le message de confirmation après génération d’une proposition annonce aussi l’étape restante, et le bouton « Annuler » des cartes validées devient « Annuler la validation » - fini l’ambiguïté avec un simple abandon.

Ajouté

• Barre de navigation interne dans le panneau des requêtes (affichée dès 7 tables) : champ « Chercher une table… » et filtres par état avec compteurs - Repli cassé, Réécritures sûres, SQL natif (IA), Embarquées. Un indicateur « X/N affichées » rappelle le filtre actif, et un lien « Tout réafficher » évite toute impasse.
• Les cartes de tables se replient en lignes compactes (nom, nombre de lignes, badges d’état) : un clic déplie le diagnostic complet. Les listes courtes restent entièrement dépliées comme avant.

Modifié

• Les liens « voir cette table » (depuis les tables lourdes du panneau Mémoire) déplient automatiquement la carte visée et réinitialisent recherche et filtres avant d’y défiler - le lien ne peut plus tomber sur une carte masquée.

Ajouté

• État des lieux en direct dans la carte « Déport vers Power Query » : nombre de colonnes candidates, traduites, cochées pour le déport (dont celles qui partiront « à la source » en SQL) et retenues par le seuil des grosses tables. Chaque case cochée dans une carte de colonne s’y reflète immédiatement - plus besoin de recouper de tête les différents panneaux.
• Renvois croisés : chaque panneau de colonne a un lien « Réglages globaux du déport » qui remonte au poste de commande, et l’avertissement « Déport reporté (table trop grande) » emmène directement au réglage du seuil où forcer la table.

Modifié

• Le texte d’introduction de la carte explique les trois chemins qui se combinent : le déport en masse (colonnes simples), le réglage colonne par colonne dans les cartes (avec l’option « à la source (SQL) »), et le seuil qui protège les grosses tables.

Ajouté

• À la première ouverture d’un rapport, une invite « Quel est ton objectif prioritaire ? » propose les objectifs directement au centre de la page (avec le nombre d’optimisations concernées) - plus besoin de repérer les petites pastilles du rail latéral. Un clic suffit, et « Peu importe, tout voir » l’écarte définitivement pour ce rapport.
• Quand des objectifs sont actifs, un bandeau permanent rappelle le ciblage et indique combien d’optimisations hors objectifs sont masquées, avec un bouton « Tout afficher » - fini les optimisations qui disparaissent sans explication.
• La barre de synthèse affiche désormais la « Prochaine action » recommandée : importer la volumétrie, traiter la prochaine étape (avec le nombre d’éléments restants), ou générer le .pbip quand tout est traité - un clic t’y emmène.
• La durée de conservation du fichier source (7 jours) est enfin visible : échéance affichée sur chaque rapport de la liste et dans l’en-tête de la page d’analyse, avec un message clair quand le fichier a expiré (les résultats d’analyse restent conservés).

Modifié

• Mobile : la barre d’actions du bas réserve désormais exactement sa hauteur (elle ne recouvre plus le contenu) et ne peut plus occuper plus de 60 % de l’écran ; le tableau des colonnes supprimables devient défilable horizontalement au lieu d’être tronqué.
• Messages plus clairs à l’inscription (délai de validation indicatif, inutile de retenter avant l’email d’approbation) et à la connexion (mention de la validation en attente pour les comptes récents). L’encart « Fidélité et limites » explique les termes techniques (mémoire VertiPaq, temps DAX) en langage courant.

Ajouté

• Nouveau bouton « Proposer le déport à la source (SQL, IA) » sur les colonnes déportables dont la table lit une requête SQL native : l’IA traduit le calcul DAX en expression SQL strictement équivalente (DAX et SQL anonymisés ensemble avant envoi, identifiants restaurés au retour, toute référence inconnue rejetée). À la génération, la requête d’origine devient une sous-requête et la colonne un SELECT calculé par le serveur - prioritaire sur le déport Power Query, et non soumis au seuil de lignes (aucun coût local).
• Sécurité : chaque expression SQL est re-validée avant injection (jamais d’instruction, de commentaire ou de point-virgule), un ORDER BY final est retiré quand c’est prouvé sûr, et tout cas ambigu (plusieurs requêtes SQL, requête absente) est ignoré avec une raison affichée - jamais de devinette.

Inclus

• Comme tout déport, la fidélité stricte ne peut pas être garantie automatiquement (BLANK/NULL, arrondis, casse) : les points à vérifier sont affichés, compare quelques lignes après actualisation.

Modifié

• La carte compte les colonnes calculées « full-scan » (LOOKUPVALUE, FILTER, SUMX…) et les tables calculées dérivées, et affiche un avertissement explicite : pendant la validation finale, leur recalcul matérialise des résultats non compressés, le pic réel peut dépasser l’estimation d’un ordre de grandeur, et le moteur de Desktop ne s’autorise qu’environ 60 % de la RAM du poste. Le libellé du pic précise « hors recalcul transitoire ».

Ajouté

• Import des compteurs de performances (panneau Mémoire) : un mode d’emploi pas à pas (2 minutes, pendant une actualisation), un collage de la table générée par Desktop, et l’app calcule le pic réel de mémoire du moteur d’extraction - le maximum, dans le temps, de la somme des évaluations simultanées - ainsi que la plus grosse évaluation seule et le top des évaluations gourmandes. Le tout comparé au pic estimé, pour valider (ou corriger) le diagnostic.
• Le format des compteurs varie selon la version et la langue de Power BI : l’import détecte les colonnes par leur nom (CSV, TSV ou point-virgule, guillemets et séparateurs de milliers tolérés) et explique précisément quoi corriger si le collage n’est pas reconnu.

Ajouté

• Recette de fusion pour les colonnes qui lisent dans une autre table : l’app déduit les clés de jointure (de la relation du modèle pour RELATED, de l’expression elle-même pour LOOKUPVALUE, y compris multi-critères) et génère les étapes Power Query prêtes à coller (fusion + développement de colonne). Quand l’expression est exactement le lookup, la colonne développée remplace directement la colonne calculée ; sinon, le calcul restant (devenu local) est affiché, traduisible par le bouton IA existant.
• Quand la fusion n’est pas générée (pas de relation active, plusieurs tables sources, valeur par défaut, critère calculé), la carte explique précisément pourquoi et quoi faire.

Inclus

• Un avertissement de fidélité accompagne chaque recette : une fusion et RELATED/LOOKUPVALUE peuvent différer sur les cas limites (doublons de clés, valeurs vides, casse) - compare quelques lignes après actualisation avant de supprimer la colonne DAX.

Modifié

• L’alerte « Table calculée » identifie maintenant les tables DAX dérivées d’une autre table du modèle (FILTER, SELECTCOLUMNS… sur une table existante) : elle nomme la ou les tables sources, explique le double stockage et le coût de reconstruction à chaque actualisation, passe en impact élevé, et propose la conversion en requête Power Query référencée (mêmes filtres et colonnes, calcul replié vers la source) ou en vue SQL. Les chaînes de copies (une copie de copie de copie…) deviennent visibles d’un coup d’œil.

Inclus

• Les findings étant calculés à l’analyse, re-téléverse un rapport déjà analysé pour voir la détection enrichie.

Ajouté

• Carte « Pic mémoire à l’actualisation » dans le panneau Mémoire (dès que la volumétrie est importée) : copie double du modèle pendant la transaction (≈ 2×), caches d’extraction Table.Buffer chiffrés en fourchette (format non compressé, ≈ 10 à 30× la taille compressée, tables les plus lourdes listées), et recalcul de fin d’actualisation (colonnes et tables calculées). Avec les remèdes : re-générer le fichier (déport sans cache mémoire) et les réglages Power BI Desktop à ajuster (nombre d’évaluations simultanées, mémoire par évaluation).

Ajouté

• Règle « Pression mémoire à l’actualisation » : dès que 3 tables ou plus utilisent une mise en cache intégrale (Table.Buffer / List.Buffer), une alerte de niveau élevé liste les tables concernées (en signalant les plus larges), explique pourquoi l’actualisation locale peut échouer par manque de mémoire, et recommande les réglages Desktop (nombre d’évaluations simultanées, mémoire par évaluation) ainsi que l’alternative Table.StopFolding sans coût mémoire.

Modifié

• L’alerte existante « Repli de requête cassé » mentionne désormais aussi le coût mémoire de Table.Buffer (la table entière retenue en RAM, environ 10 à 30 fois sa taille finale) et l’alternative Table.StopFolding.

Inclus

• Les findings étant calculés à l’analyse, re-téléverse un rapport déjà analysé pour voir la nouvelle règle s’appliquer.

Corrigé

• Sur un modèle avec beaucoup de tables déportées, l’actualisation locale pouvait saturer la mémoire : chaque table déportée était intégralement chargée en RAM (Table.Buffer, format non compressé, plusieurs tables en parallèle). Le fichier généré utilise désormais Table.StopFolding : ta requête SQL s’exécute toujours telle quelle côté serveur (même protection qu’avant contre la sous-requête qui faisait pendre le rafraîchissement), mais les lignes défilent en flux, sans être retenues en mémoire. À noter : Table.StopFolding nécessite un Power BI Desktop d’août 2022 ou plus récent.
• Les sources qui ne délèguent pas leurs calculs à un serveur (SharePoint, Excel, tables saisies…) n’ont plus aucun emballage : il n’y avait rien à protéger, et la mise en cache y était de la mémoire consommée pour rien.
• Effet de bord corrigé au passage : le fichier généré ne déclenchait plus l’alerte « repli vers la source interrompu » de… notre propre moteur de règles.

Ajouté

• La suppression d’un rapport demande désormais une confirmation explicite (avec le nom du rapport et un rappel de ce qui sera perdu) - fini la suppression définitive sur un simple clic d’icône.

Corrigé

• En cas de problème (réseau coupé, session expirée, erreur serveur), la page d’analyse affichait… une page blanche. Elle affiche maintenant un message clair et un bouton « Réessayer ». Les panneaux Colonnes supprimables, Classement mémoire et Analyse des requêtes font de même - et ne prétendent plus à tort que « la rétention de 7 jours est dépassée » quand c’est le réseau qui flanche.
• Les messages d’erreur techniques (codes anglais, détails de validation) sont désormais traduits en français clair avant d’être affichés, sur toutes les pages.
• Sur « Mot de passe oublié », un envoi qui échouait (trop de tentatives, réseau) ne produisait aucune réaction : l’erreur s’affiche désormais. Et sur la page de connexion, une coupure réseau ne laisse plus le bouton bloqué sur « Connexion en cours… ».

Corrigé

• La suppression d’un compte (par l’utilisateur ou par refus de l’administrateur) effaçait les analyses mais laissait les fichiers .pbip dans le stockage, hors de portée de la purge automatique. Ils sont désormais tous supprimés du stockage au moment même de la suppression du compte, comme le promettent la politique de rétention et le RGPD.
• Lors d’une réécriture Power Query assistée par l’IA, le code envoyé contenait les identifiants de connexion en clair (nom du serveur, de la base, URL internes, chemins de fichiers). Ils sont désormais remplacés par des jetons anonymes avant l’envoi, puis restaurés dans la réponse - l’IA ne voit jamais ton infrastructure, comme c’était déjà le cas pour les requêtes SQL.

Ajouté

• Budget d’analyse IA : chaque compte dispose d’un plafond de dépense sur 24 heures glissantes (5 $ par défaut, ajustable par l’administrateur). Au-delà, les fonctions IA (réécriture, cohérence, optimisation SQL, déport) répondent par un message clair et se libèrent automatiquement au fil des heures.
• Vérification de la taille réelle des fichiers : la limite de 500 Mo est désormais contrôlée sur le fichier réellement reçu par le stockage, plus seulement sur la taille annoncée par le navigateur. Un fichier trop lourd est refusé avant tout traitement et retiré du stockage, avec un message explicite.
• Protection contre les archives piégées (« zip bomb ») : une archive qui annonce un contenu décompressé démesuré (plus de 2 Gio) est refusée avant toute décompression, à l’analyse comme à la génération.

Ajouté

• 40 nouveaux tests automatisés sur les modules qui décident du contenu de tes analyses : le moteur de règles (relations bidirectionnelles, clés de relation en texte y compris composites calculées, tables date/heure automatiques, intelligence temporelle sans table de dates, divisions sans DIVIDE), la détection des colonnes supprimables (la « cascade » qui protège les colonnes de tri, de hiérarchie et les dépendances conservées), la classification déport Power Query (noms de tables avec espaces, casse ou apostrophes - la famille de bugs corrigée deux fois par le passé), et les alertes de cohérence des formules (comparaisons toujours vraies, branches identiques, division par zéro).

Ajouté

• Une suite de 26 tests automatisés (vitest) couvre le moteur d’optimisation des requêtes et la génération des fichiers : chaque cas piège corrigé en v1.33.1 est rejoué automatiquement, et le contrôle d’intégrité post-génération est vérifié dans les deux sens (il accepte les suppressions volontaires, il bloque les disparitions imprévues et les fichiers illisibles).

Corrigé

• L’optimisation « ORDER BY de tri retiré » pouvait tronquer une requête SQL si les mots « order by » apparaissaient dans un commentaire : tout ce qui suivait disparaissait de la requête. L’analyse distingue désormais le vrai code des commentaires et des textes entre guillemets.
• L’optimisation « Étape sans effet retirée » supprimait un vrai filtre quand il commençait par « each true and… » (des lignes en plus étaient alors chargées). Seul un filtre littéralement « toujours vrai », sans aucune condition, est maintenant retiré.
• La fusion de deux étapes de typage n’est plus proposée quand une même colonne est convertie dans les deux (par exemple date, puis texte, puis nombre) : appliquées d’un coup, les conversions ne donnaient pas le même résultat qu’à la suite.
• Lors du déport de colonnes calculées, un commentaire « // » à la fin de la requête d’origine pouvait avaler la ponctuation ajoutée par l’outil et produire un fichier impossible à ouvrir dans Power BI.

Ajouté

• Contrôle d’intégrité post-génération : chaque fichier généré est relu et comparé au modèle d’origine (tables, colonnes, mesures, relations). S’il manque quoi que ce soit d’imprévu, la génération est annulée avec un message clair - jamais de fichier abîmé livré comme « appliqué ».

Corrigé

• « Clé de relation en texte » (Restructurer) ne repérait que les colonnes de type texte déclaré, et ratait donc les clés composites calculées (COMBINEVALUES, concaténations…) qui n’ont pas de type stocké - alors qu’elles sont souvent les plus lourdes. Elle utilise désormais la même détection que la carte « Clés texte lourdes ». Une entrée est créée par colonne-clé texte (au lieu d’une par relation), pour coller à la carte et être classée par impact mémoire réel.

Inclus

• Cette amélioration s’applique aux rapports analysés à partir de maintenant : pour la voir sur un rapport déjà analysé, re-téléverse-le (la carte « Clés texte lourdes », elle, est déjà à jour en direct).

Corrigé

• L’encart « À retirer de tes requêtes source » qui apparaît après génération n’avait pas de bouton pour le fermer : il fallait recharger la page (F5) et perdre tous les réglages faits avant la génération. Il a maintenant un bouton ✕ (et sa liste, si longue, défile au lieu de tout pousser).

Modifié

• Le « plan d’action à réaliser post génération » téléchargeable inclut désormais une dernière section « Retirer des requêtes source les colonnes supprimées (avant actualisation) » : un seul document cohérent avec le .pbip généré, à dérouler avant de lancer l’actualisation des données. Le bouton de téléchargement reste disponible même quand il n’y a que ce nettoyage à faire.

Corrigé

• « Clés texte lourdes » : les colonnes calculées composites construites avec COMBINEVALUES (ou CONCATENATE, FORMAT, LEFT/RIGHT…) étaient considérées non-texte (car une colonne calculée n’a pas de type déclaré) et donc jamais proposées, alors qu’elles sont souvent les plus lourdes en mémoire. Elles sont maintenant reconnues comme du texte.

Modifié

• « Clés texte lourdes » : une clé n’est désormais exclue que si elle est affichée dans un visuel/filtre ou utilisée par une mesure (là où un entier opaque casserait quelque chose). Une clé référencée seulement par d’autres colonnes reste proposée, avec la mention « aussi référencée par… » pour te rappeler de mettre ces colonnes à jour.

Corrigé

• Carte « Déporter en Power Query » : quand une colonne est bloquée (elle dépend d’une colonne calculée restant en DAX), l’étiquette du haut affichait encore « Déportable en Power Query » (verte), en contradiction avec l’avertissement juste en dessous. Elle affiche désormais « Non déportable seule » et la phrase « traduisible en Power Query » (trompeuse) est masquée.

Corrigé

• Déport Power Query : la détection de dépendance vers une colonne calculée restant en DAX comparait les noms de façon exacte, donc un nom avec une espace superflue (ex. « Clé L2-L3 » à double espace) ou une casse différente passait au travers - la colonne était encore proposée au déport. La comparaison est désormais insensible aux espaces superflus et à la casse (comme pour les colonnes supprimables).

Modifié

• « Clés texte lourdes » : ne liste plus que les colonnes texte à forte cardinalité qui sont utilisées dans une relation ET référencées par rien d’autre (ni une autre colonne, ni une mesure, ni un visuel). Une clé aussi affichée ou réutilisée ailleurs ne peut pas être simplement remplacée par un entier opaque : elle est donc exclue du recensement.

Modifié

• Bandeau du bas : la case « Supprimer les X sélectionnés » est retirée. Les colonnes cochées dans « Colonnes supprimables » sont désormais retirées automatiquement à la génération du .pbip. Pour en conserver, il suffit de les décocher dans ce panneau.
• Le bouton « Générer le .pbip » du bandeau s’active aussi quand il n’y a que des suppressions à appliquer (avant, il fallait une autre optimisation).

Corrigé

• Déport Power Query : quand une colonne calculée s’appuie sur une autre colonne calculée qui reste en DAX (non déportable), l’option « Déporter automatiquement » est désormais désactivée avec un avertissement (« déport impossible seule : dépend de … »). Le fichier généré était déjà protégé (cette colonne était écartée à la génération) ; c’est la proposition à l’écran qui était trompeuse.

Modifié

• Le classement des optimisations est désormais piloté par tes objectifs déclarés et leur ordre de priorité : à l’intérieur de chaque étape, les optimisations qui servent ton objectif n°1 passent devant celles du n°2, et ainsi de suite. Sans objectif sélectionné, le classement par impact réel est inchangé.
• L’impact réel d’une optimisation utilise la mémoire réelle mesurée (octets) quand elle est disponible, en plus de la cardinalité et du nombre de lignes - une colonne dont on connaît le vrai poids est priorisée sur ce poids.

Ajouté

• Carte « Clés texte lourdes » (en tête des mesures, à droite) : détecte les colonnes texte à forte cardinalité d’après la volumétrie/mémoire importée - quel que soit leur nom - et recommande de les remplacer par une clé entière de substitution (le poste mémoire n°1). Chaque clé est étiquetée « relation », « composite » (concaténation) ou « texte », avec son poids réel.

Modifié

• La détection des colonnes « identifiant » reconnaît maintenant « clé/cle/clef » (et pas seulement les mots anglais « id/key/code »), en mot entier, en préfixe comme en suffixe.

Modifié

• Panneau de droite regroupé : une carte « Tables » (nombre de lignes + mémoire par table) et une carte « Colonnes » (cardinalité + mémoire par colonne), placées juste sous « Contexte du modèle ». Les requêtes à jouer dans Power BI (volumétrie, mémoire) descendent en dessous, sous les résultats qu’elles alimentent.
• Nouveau : la mémoire est aussi agrégée par table (somme des colonnes), en plus du détail par colonne.

Corrigé

• Le badge de statut de l’étape « Mesurer » (« fait » / « à faire ») utilisait un style différent des autres étapes. Il est désormais uniforme (même pastille verte que « Nettoyer », « Alléger », etc.).

Corrigé

• La requête « Mémoire réelle » échouait dans Power BI (« colonne 'DictSize' introuvable »). Elle a été réécrite de façon plus robuste : elle fait correspondre les tailles de dictionnaire et de données par identifiant interne de colonne (au lieu d’une jointure fragile), validée sur un vrai modèle.

Corrigé

• La section « Mémoire réelle » (et sa requête DAX à copier) était masquée sur les rapports analysés avant l’ajout de la collecte de volumétrie. Elle est maintenant toujours visible dans le panneau de droite « Volumétrie & cardinalité », car la mesure de mémoire ne dépend pas de l’analyse.

Ajouté

• Section « Mémoire réelle (VertiPaq) » dans le panneau de volumétrie : une requête unique (valable pour tous les modèles) à jouer dans la vue requête DAX de Power BI. Elle lit les tailles internes du moteur et ne renvoie que des tailles, jamais une donnée. Colle le résultat, importe : le poids réel de chaque colonne est enregistré.
• Le classement « Impact mémoire » et le gain « libère X » des colonnes supprimables utilisent les octets réels dès qu’ils sont mesurés (et affichent « mesuré » au lieu de « estimé » / « ≈ »). Les colonnes sans mesure gardent l’estimation.

Inclus

• Nécessite une version récente de Power BI Desktop (fonctions DAX INFO.*). La mesure est indépendante de la volumétrie : tu peux importer l’une, l’autre, ou les deux.

Ajouté

• Nouveau panneau « Impact mémoire (estimé) » : classe les colonnes par poids mémoire VertiPaq estimé (à partir de la cardinalité, du volume et du type déjà collectés - aucune nouvelle manipulation). Les colonnes lourdes ET inutilisées sont signalées « morte » pour repérer d’un coup d’œil le meilleur gain.
• Le panneau « Colonnes supprimables » chiffre désormais la mémoire libérée : une colonne « Mémoire est. » par élément, un total « libère ≈ X » en tête, et la colonne est ajoutée à l’export CSV.

Inclus

• L’estimation est un ordre de grandeur (proxy) : la mesure exacte des octets réels VertiPaq arrivera avec la capture directe depuis le moteur.

Corrigé

• Déport et seuil de taille : une colonne calculée cochée pour déport dont la table dépasse le seuil (et non forcée) était affichée « Déportée vers Power Query » et comptée comme traitée, alors qu’à la génération elle reste en DAX (garde-fou anti-ralentissement du refresh). Elle affiche désormais « Déport reporté (table trop grande) » avec un rappel pour forcer la table dans « Seuil de déport », reste dans les « à traiter » (bandeau + barre du bas), et n’est plus comptée parmi les déports appliqués. Cohérent avec ce qui est réellement écrit dans le .pbip.

Corrigé

• Détection des colonnes supprimables : une colonne dont le nom contient une espace en trop (début/fin) était considérée à tort comme inutilisée, même quand une colonne calculée d’une AUTRE table la référençait (via LOOKUPVALUE/RELATED). Elle était alors supprimée, et toutes les colonnes calculées qui en dépendaient tombaient en erreur en cascade (colonne introuvable, puis comparaisons « Integer vs Text »). La comparaison des noms est désormais insensible aux espaces superflus (comme l’est déjà l’extraction des références). Si tu avais généré un fichier touché : régénère-le, la colonne sera conservée.

Ajouté

• Dévalidation colonne par colonne des changements de type : quand la case globale « Changements de type » est cochée, chaque colonne date-heure/flottante affiche une case « appliquer à cette colonne ». Décoche-la pour exclure cette colonne précise (elle reste en l’état et repasse en « à valider »), sans toucher aux autres. L’exclusion est bien prise en compte à la génération.

Corrigé

• Case « Changements de type » : c’est une action globale. La cocher considère maintenant TOUTES les colonnes date-heure/flottantes concernées (non ignorées) comme traitées - leur carte affiche « Type corrigé », elles ne comptent plus dans les « à valider » (bandeau et barre du bas), et le changement s’applique à la génération sans avoir à valider chaque colonne une à une. Décoche une colonne (Ignorer) pour l’exclure.

Corrigé

• Colonnes calculées déportées : une colonne marquée pour le déport en Power Query (déport en masse, colonne par colonne, ou grosse table forcée) est désormais traitée comme VALIDÉE partout - sa carte affiche « Déportée vers Power Query » (plus le bouton « Valider »), et elle ne compte plus dans les « à traiter » du bandeau ni de la barre du bas.
• Nettoyage interne : suppression d’un écran d’optimisation devenu inutilisé (parcours par objectif remplacé par le bandeau).

Modifié

• Synchronisation de la sélection des colonnes supprimables : quand tu décoches une colonne dans le panneau « Colonnes supprimables », les compteurs de l’étape « Nettoyer » (bandeau gauche, au format X/Y) et le résumé de la barre du bas se mettent à jour immédiatement. La génération depuis la barre ne retire désormais que les colonnes réellement cochées (au lieu de tout supprimer).

Modifié

• Bandeau gauche : les compteurs passent au format « traité-ou-validé / proposé » (ex. 70/80). Chaque type d’optimisation dans le zoom d’une étape, et chaque étape elle-même, indique désormais combien sont traités/validés sur le total proposé (pastille verte quand tout est traité).

Modifié

• Barre du bas retravaillée : format homogène (même taille de police) et, pour chaque optimisation, le nombre traité/validé vs proposé (Optimisations X/Y, Suppressions, Déports Power Query, Requêtes embarquées). Les options de génération (supprimer les supprimables, changements de type, optimiser les requêtes) y sont rapatriées, à côté du bouton « Générer le .pbip ».
• Les cartes de déport (« Déport vers Power Query », « Tout déporter », « Seuil de déport ») sont maintenant en tête de l’étape « Alléger », là où on traite les colonnes calculées - au lieu d’être isolées en haut de page.
• Cartes retirées : « Générer le rapport optimisé » au milieu de la page (la génération se fait désormais depuis la barre du bas).
• Carte « Ton plan d’action » (remplacée par le bouton de téléchargement dans la barre du bas).
• Carte « Tables lourdes : optimiser la requête puis déporter (combo) » (redondante avec le déport intégré à « Alléger » et le panneau des requêtes).

Ajouté

• Bouton « Télécharger le plan d’action à réaliser post génération du .pbip » dans la barre du bas, à droite de « Générer le .pbip » (remplace la carte « Ton plan d’action »).

Ajouté

• Zoom par étape dans le bandeau gauche : chaque étape se déplie (chevron) pour lister les TYPES d’optimisation qu’elle contient (ex. « Colonne calculée matérialisée », « Colonne date-heure à granularité fine »…) avec leur nombre. Un clic sur un type filtre le panneau central sur ce seul type et t’y amène - indispensable quand une étape contient des centaines d’optimisations (ex. « Alléger »). Un bandeau « Filtré sur : … / Tout afficher » rappelle le filtre actif.
• Résumé des suppressions en bas du bandeau gauche : nombre de colonnes importées, de colonnes calculées (et de mesures) à retirer, d’un coup d’œil.
• Résumé des optimisations traitées dans la barre du bas : « Tu traites N optimisations validées · M à supprimer », pour garder une vue d’ensemble de ce que tu vas générer.

Corrigé

• Statut de l’étape « Nettoyer » : les éléments supprimables (colonnes mortes/inutilisées, mesures inutilisées) sont gérés dans leur propre panneau et n’étaient donc pas comptés dans la progression de l’étape - qui affichait « rien à faire » même quand tout était coché. Ils sont désormais intégrés à l’avancement de « Nettoyer » : cochés par défaut (donc validés pour suppression), l’étape passe à « fait » dans la carte centrale et affiche la pastille verte dans le bandeau gauche, comme l’étape « Mesurer ».

Ajouté

• Bandeau de navigation vertical à gauche du rapport. En haut, tes objectifs (Réduire la mémoire, Accélérer le refresh…) sous forme de puces à activer : ils filtrent les étapes sur ce qui sert vraiment ton but. En dessous, les 6 grandes étapes (Mesurer, Nettoyer, Alléger, Restructurer, Affiner, Peaufiner) avec, pour chacune, le nombre d’actions restantes et une barre de progression globale. Un clic sur une étape déroule ses actions dans le panneau central et t’y amène directement - fini de chercher où se trouve telle optimisation (par ex. les changements de format).

Modifié

• Le parcours central est désormais unifié autour des étapes, piloté par le bandeau gauche : choisir des objectifs filtre les étapes au lieu de réorganiser toute la page. Le sélecteur d’objectifs en pleine largeur et la barre de raccourcis en haut sont remplacés par le bandeau, plus compact et toujours visible.

Corrigé

• Corrections de type (datetime→date, montant flottant→décimal) : l’identification de la colonne cible était fragile quand le nom de la colonne ou de sa table contenait des crochets (même faille que celle corrigée en 1.22.14 pour les suppressions). La cible est maintenant résolue contre le modèle en testant chaque découpe possible et en gardant celle qui désigne une vraie colonne. Aucun impact si tes colonnes de dates/montants ont des noms simples.

Corrigé

• Suppression des colonnes/mesures : les noms « spéciaux » sont désormais correctement retrouvés et retirés du modèle. Trois cas échouaient en silence (l’élément restait dans le fichier alors qu’il était coché) : une apostrophe dans le nom (le format TMDL la double, ex. « Saison de création d’échantillon »), un nom de colonne contenant des crochets (ex. « SKU PF colorées et tailles[ColorwayFullName] »), un nom de table contenant des crochets (ex. « [Façonniers] … »), ainsi qu’un espace final significatif. Vérifié sur un vrai rapport : 173 éléments validés, 173 réellement supprimés (contre ~136 auparavant).

Modifié

• Fiabilité de la traduction DAX→Power Query industrialisée : tous les pièges rencontrés (fonctions inventées, concaténations/clés, dates, types…) sont désormais centralisés dans un registre unique où chaque entrée paire sa PRÉVENTION (règle injectée dans le prompt IA) et son FILET DE SÉCURITÉ (garde-fou déterministe à la génération). Le prompt est généré depuis ce registre, avec un mode d’emploi pour ajouter un nouveau cas en une fois. Aucun changement de comportement pour cette version - c’est une base pour durcir l’outil plus vite à chaque bug futur.

Modifié

• Consigne de traduction IA renforcée sur les concaténations et les clés : DAX (`&`, COMBINEVALUES) convertit chaque membre en texte et traite un BLANK comme chaîne vide, alors qu’en Power Query un membre null rend toute la concaténation null (clé de relation vide refusée) et un membre numérique lève une erreur de type. L’IA doit désormais envelopper chaque membre : (Text.From([A]) ?? "") & "-" & (Text.From([B]) ?? ""). Les traductions futures sont donc correctes dès la source ; le garde-fou de génération (1.22.11) reste le filet de sécurité.

Corrigé

• Clé de relation déportée vide à l’actualisation (« contient des valeurs vides, non autorisé… »). Une clé DAX comme COMBINEVALUES("-", [A], [B]) ou [A] & "-" & [B] était traduite naïvement en [A] & "-" & [B] : en Power Query, si [A] ou [B] est vide (null), toute la concaténation devient null → clé vide refusée par Power BI. Désormais chaque colonne concaténée est rendue null-safe et type-safe automatiquement : (Text.From([A]) ?? "") & "-" & (Text.From([B]) ?? ""), exactement comme DAX (conversion en texte, BLANK traité comme chaîne vide). Corrige d’un coup les ~27 colonnes-clés concernées du rapport.

Corrigé

• Déport + embarquement sur la même table : ils se COMBINENT désormais au lieu de s’exclure (la 1.22.9 les rendait exclusifs à tort). L’embarquement est appliqué d’abord (ta requête optimisée devient la source), puis le déport greffe ses colonnes calculées par-dessus, via Table.AddColumn. C’est tout l’intérêt : optimiser la requête pour dégager du temps d’extraction ET y loger les colonnes déportées.
• Inférence de type des colonnes déportées corrigée : une colonne qui produit du TEXTE (concaténation « & », littéral, Text.*) mais qui traînait un format d’affichage numérique (formatString 0) était typée en nombre → erreur « comparaison Integer vs Text » à l’actualisation. Le corps Power Query prime maintenant sur le format quand il est clairement du texte.

Corrigé

• Colonnes « introuvables » à l’actualisation quand une table avait À LA FOIS un embarquement de requête ET des colonnes calculées déportées : l’embarquement remplace toute la requête Power Query et supprimait les colonnes ajoutées par le déport, laissant les colonnes converties pointer dans le vide. Désormais, sur une table embarquée, le déport est ignoré (colonnes laissées en DAX) et signalé dans les « ignorés ». L’embarquement gagne ; les colonnes calculées continuent de se calculer à partir de ta requête réécrite.

Modifié

• La traduction IA d’une colonne calculée en Power Query reçoit une consigne renforcée : n’utiliser QUE de vraies fonctions Power Query, ne jamais inventer un nom, avec les pièges vérifiés (Number.IntegerPart / Number.Truncate n’existent pas → utiliser Number.RoundDown pour DAX INT) et des exemples de fonctions fiables. Complète le garde-fou liste blanche de la 1.22.7 : moins d’hallucinations dès la traduction, donc plus de colonnes déportables.

Corrigé

• Encore une fonction Power Query inexistante inventée par l’IA dans une colonne déportée (Number.Truncate, à nouveau pour un DAX INT()) : corrigée en Number.RoundDown comme Number.IntegerPart.

Ajouté

• Garde-fou anti-hallucination définitif : avant d’embarquer une colonne déportée, l’app vérifie que sa traduction n’utilise QUE de vraies fonctions Power Query (liste blanche). Toute colonne dont la traduction appelle une fonction non reconnue est laissée en DAX (déport ignoré et signalé) au lieu de casser l’actualisation. Au pire on déporte une colonne de moins ; l’actualisation ne casse plus jamais à cause d’une fonction M inventée.

Ajouté

• Dans le bandeau « Prêt à générer », le nombre de « requêtes embarquées » est désormais cliquable : il déplie la liste de toutes les requêtes embarquées (y compris d’anciens essais dont la carte de table n’est plus visible), avec un bouton « Retirer » par requête et un « Tout réinitialiser ». Tu gardes ainsi uniquement les requêtes que tu as confirmées, et tu peux purger les résidus avant de générer.

Corrigé

• Actualisation des données bloquée (« Le nom Number.IntegerPart n’a pas été reconnu ») : la traduction IA d’une colonne calculée déportée (un DAX INT()) utilisait une fonction Power Query qui n’existe pas. Comme la table concernée est référencée par beaucoup d’autres, l’erreur se propageait à des dizaines de requêtes. Les noms de fonctions M inventés par l’IA sont désormais corrigés automatiquement (Number.IntegerPart devient Number.RoundDown, l’équivalent exact de DAX INT), à la traduction comme à la génération du fichier.

Corrigé

• Cause racine enfin trouvée de l’erreur « Erreur du moteur M : Jeton ';' attendu » : quand une table avait une propriété de partition non reconnue (par ex. queryGroup), le nettoyage de la requête la repliait dans le code Power Query, et l’embarquement réinjectait alors un second « source = » et la propriété au milieu de la requête - rendant la partition invalide. Le nettoyage ignore désormais toute propriété de partition (queryGroup, dataView, …) avant la requête. L’embarquement d’une requête réécrite fonctionne maintenant, y compris sur les tables rangées dans un groupe de requêtes.

Modifié

• Garde-fou d’embarquement de nouveau minimal : il ne bloque QUE le cas où l’on colle par erreur le script de validation. Le blocage des requêtes « multi-instructions » (DECLARE, plusieurs « ; ») introduit en 1.22.3 était basé sur un mauvais diagnostic - Power BI accepte parfaitement un DECLARE dans une requête source. Tu peux donc embarquer ta requête telle quelle, sans la réécrire en une seule instruction.

Corrigé

• Vraie cause de l’erreur « Jeton ';' attendu » à l’ouverture du .pbip : une requête source Power BI doit être UNE seule instruction. Pour détecter les colonnes, Power BI enrobe ta requête dans une sous-requête (SELECT * FROM (ta requête) AS _), ce qui est impossible avec un DECLARE ou plusieurs instructions séparées par « ; ». L’embarquement détecte et refuse maintenant ces requêtes multi-instructions, avec un message qui explique comment réécrire en une seule instruction (remplacer les variables @… par leur expression, ex. @CurrentDate par CAST(GETDATE() AS DATE)). Un point-virgule final isolé reste accepté (il est retiré automatiquement).

Modifié

• Le brief « Confier la réécriture à un agent sans limite » inclut désormais une contrainte impérative : produire UNE seule instruction SQL (pas de DECLARE/variables, pas de tables temporaires #, pas de « ; » multiples), pour que la requête réécrite soit directement embarquable dans le .pbip.

Corrigé

• Embarquement d’une requête réécrite : les requêtes écrites sur plusieurs lignes (avec sauts de ligne ou lignes vides, par ex. un DECLARE suivi d’un SELECT, ou une CROSS APPLY mise en forme) cassaient le fichier généré, qui refusait alors de s’ouvrir dans Power BI (« Erreur du moteur M : Jeton ';' attendu »). La requête est désormais réinjectée sur une seule ligne technique (les sauts de ligne sont encodés au format Power Query), ce qui produit exactement le même SQL côté serveur mais un fichier toujours valide. Réimporte ta requête et régénère le rapport.

Modifié

• Garde-fou d’embarquement moins restrictif : il acceptait mal certaines requêtes réécrites en externe (multi-instructions, DECLARE, etc.). Désormais il ne bloque QUE le cas évident où l’on colle par erreur le script de validation lui-même (reconnu à son en-tête « Script de validation » dans les premières lignes). Toutes les autres réécritures sont acceptées - sous ta responsabilité, après validation par le script.

Modifié

• Mise en page élargie : la page d’un rapport utilise mieux la largeur de l’écran (jusqu’à 1600 px au lieu de ~1150) et le bandeau latéral passe de 360 à 420 px - les nombres de volumétrie et de cardinalité s’affichent désormais en entier, sans être tronqués.
• La carte d’ajout des rapports liés / paginés (une étape de préparation des données à faire avant que pbi-optimizer livre ses meilleures propositions) rejoint le bandeau latéral, aux côtés de la volumétrie et du contexte du modèle - elle est ainsi plus facile à trouver, au lieu d’être enfouie dans le parcours.

Corrigé

• Compteur de déports du bandeau : il comptait les déports marqués sans tenir compte du garde-fou de taille. Désormais il reflète ce qui sera RÉELLEMENT appliqué - une grosse table au-dessus du seuil et non forcée (donc qui serait laissée en DAX) n’est plus comptée. Conséquence : cocher « Déporter quand même » sur une grosse table fait maintenant monter le compteur, et le bandeau affiche en plus « N grosses tables forcées ».

Modifié

• Tri par impact : dans « Accélérer le chargement » et dans le combo « tables lourdes », les tables sont désormais classées par volume décroissant (les plus grosses d’abord) au lieu de l’ordre alphabétique - pour traiter en priorité ce qui pèse le plus. Chaque carte affiche son nombre de lignes.
• Lien direct : depuis une carte du combo « tables lourdes », « Aller à l’optimisation des requêtes » mène désormais directement à la carte de CETTE table dans « Accélérer le chargement » (plus de défilement pour la retrouver).

Corrigé

• Garde-fou d’embarquement trop strict (régression 1.20.1) : il bloquait toute requête « multi-instructions », ce qui empêchait d’embarquer une requête commençant par un DECLARE (ex. « DECLARE @CurrentDate DATE = GETDATE(); ») suivi d’un SELECT/WITH - pourtant parfaitement valide comme source Power Query. Le garde-fou autorise désormais un préambule DECLARE/SET + une seule requête SELECT/WITH, et ne bloque que ce qui casse réellement (tables temporaires … INTO #…, DROP/CREATE/EXEC, ou plusieurs requêtes).

Modifié

• L’en-tête du script de validation nomme la table : « Script de validation genere par pbi-optimizer pour la table "…" ». Plus simple de s’y retrouver quand on en valide plusieurs.

Corrigé

• Embarquement d’une requête non valide comme source Power Query : si la réécriture contenait plusieurs instructions (séparées par « ; »), des tables temporaires (#…) ou un DROP/DECLARE en tête, l’embarquer cassait le .pbip à l’ouverture (« Erreur du moteur M : Jeton ';' attendu »). L’app bloque désormais ce cas avec un message clair - une source Power Query doit être une seule requête SELECT (CTE en ligne ou CROSS APPLY). La version avec tables temporaires reste valable pour le script de validation, pas pour l’embarquement.

Modifié

• Barre d’action collante en bas de page : un résumé (optimisations validées, colonnes déportées, requêtes embarquées) et le bouton « Générer le .pbip » restent visibles en permanence - plus besoin de remonter tout en haut pour générer.
• Déport vers Power Query regroupé en une seule carte ordonnée, en haut de l’onglet Optimisations : 1) « Tout déporter », 2) liste des colonnes, 3) réglage des grosses tables (« Déporter quand même ») - au lieu d’avoir le bouton en milieu de page et le réglage tout en haut dans la carte de génération.
• Mini-sommaire de raccourcis en tête (Déport · Requêtes · Cohérence · Générer) pour sauter directement à la bonne section.

Corrigé

• Script de validation invalide sur les réécritures multi-instructions : quand la requête réécrite matérialise d’abord ses propres tables temporaires (ex. #COLORWAY, #SKU_SITE) avant la requête finale, le « INTO #nouvelle » était inséré au mauvais endroit (sur la première étape), créant un double INTO non valide. Désormais le « INTO » est placé sur la dernière instruction SELECT qui produit le résultat (celle sans INTO), les étapes de matérialisation et les DROP sont laissés intacts.

Ajouté

• Diagnostic automatique des requêtes (8 anti-patterns courants, génériques et neutres SGBD) : UNION sans ALL, même table scannée plusieurs fois (scans répétés), CTE réévalué, fonction sur une colonne filtrée (non-sargable), LIKE avec joker en tête, NOT IN (sous-requête), SELECT *, et conversion implicite (colonne comparée à un littéral d’un autre type, via les types de colonnes). 100 % statique : aucune donnée, aucun appel IA.
• Brief du handoff enrichi : les pistes repérées et la liste colonnes → types sont injectées dans le brief prêt à confier à un agent, avec un contrat d’équivalence explicite (NULL/BLANK, types, doublons, arrondis…). L’agent démarre avec le diagnostic déjà fait, au lieu de partir de zéro. Les pistes sont aussi affichées à l’écran (présentées comme « à vérifier », jamais comme des certitudes).

Ajouté

• Embarquer une requête réécrite dans le .pbip : après avoir prouvé l’équivalence avec le script de validation, tu peux cocher « Embarquer cette requête dans le .pbip » - sur la réécriture proposée par l’IA comme sur une réécriture externe collée. À la génération, la requête native de la table est remplacée par ta version : plus besoin de la recopier à la main dans Power Query. Opt-in et sous ta responsabilité (l’app ne voit jamais tes données ; c’est toi qui confirmes l’équivalence via le script). Le choix est mémorisé par rapport, et le téléchargement confirme le nombre de requêtes embarquées.

Corrigé

• Combo « table lourde » sans action : la carte renvoyait vers le panneau « Accélérer le chargement », qui n’était visible que sous l’objectif Extraction - donc absent quand tu étais sur l’objectif Mémoire. Le panneau d’optimisation des requêtes est désormais toujours affiché, et la carte combo a un bouton « Aller à l’optimisation des requêtes » qui t’y emmène directement.

Corrigé

• Combo « table lourde » invisible : il ne s’affichait qu’après avoir déjà validé un déport - un cercle vicieux, puisque son rôle est justement de t’inciter à déporter. Il se base désormais sur la détection des colonnes calculées déportables (indépendamment de toute validation), apparaît aussi dans le parcours complet (sans objectif sélectionné), et t’indique quoi faire quand la volumétrie n’a pas encore été importée.

Ajouté

• Script de validation automatique : pour toute réécriture de requête (proposée par l’IA ou collée de l’extérieur), pbi-optimizer génère un script T-SQL qui matérialise l’ancienne et la nouvelle requête, les compare (EXCEPT dans les deux sens + total de lignes) et affiche un verdict « identique ». Déterministe, sans IA, sans envoi de données - tout tourne chez toi. Gère les cas pièges (UNION, CTE, DECLARE).
• Handoff pour les requêtes lourdes : quand une requête est trop volumineuse pour une réécriture garantie en un appel, l’app fournit un diagnostic et un brief prêt à confier à un agent sans limite (Claude Code / Claude.ai), avec une option d’anonymisation des noms ; tu colles le résultat dans « Valider une réécriture externe » pour prouver l’équivalence.
• Combo « table lourde » : sur les grosses tables à colonnes calculées, l’app séquence explicitement les deux leviers - 1) optimiser la requête source (prérequis, ne réduit pas la mémoire à lui seul) puis 2) déporter les colonnes calculées (le vrai gain mémoire + VertiPaq) - avec des avertissements clairs contre les demi-mesures.
• Déport des grosses tables au choix : le garde-fou de taille n’est plus une interdiction. Chaque grosse table dépassant le seuil peut être déportée « quand même » individuellement, sans lever le garde-fou partout.

Modifié

• Page d’accueil : les promesses décrivent désormais le parcours par objectif, l’accélération de l’extraction (repli + réécritures sûres + IA), la preuve d’équivalence et le handoff.
• Plus de marge de calcul pour l’optimiseur de requêtes IA (durée d’exécution serveur relevée).

Ajouté

• Sélecteur d’objectifs en tête de l’analyse : indiquez un ou plusieurs buts - réduire la taille mémoire, accélérer le rafraîchissement (VertiPaq), accélérer l’extraction (SQL / Power Query), accélérer l’affichage des visuels (DAX), rechercher/remplacer du texte, fiabiliser les formules - et surtout dans l’ordre de priorité qui compte pour vous. La page se réorganise en sections, une par objectif, dans cet ordre : les optimisations et les outils utiles à votre premier objectif arrivent en premier.
• Une optimisation qui sert plusieurs de vos objectifs n’apparaît qu’une seule fois (sous le plus prioritaire), avec une étiquette « compte aussi pour ». Une section repliée « Autres optimisations détectées (hors objectifs) » garantit que rien n’est masqué.

Modifié

• Sans objectif sélectionné, vous retrouvez exactement le parcours complet d’avant (Nettoyer → Alléger → Restructurer → Affiner → Peaufiner) : aucune perte de repère pour ceux qui préfèrent l’échelle par type d’action.

Ajouté

• Optimisation IA sous-requête par sous-requête (CTE) : sur une grosse requête (plusieurs CTE, beaucoup de jointures), l’IA travaillait sur le tout et ne proposait souvent rien (impossible de garantir l’équivalence à cette échelle). Désormais elle découpe la requête en sous-parties (CTE + requête principale), optimise chacune séparément, et réassemble le tout - avec un diff par sous-partie. Bien plus de chances d’obtenir une optimisation sûre sur les requêtes complexes.

Modifié

• Message plus clair quand l’IA ne trouve rien à réécrire : au lieu d’un simple « aucune optimisation », l’app explique pourquoi (requête déjà simple, ou trop volumineuse pour une garantie d’équivalence) et renvoie vers les vrais leviers - le diagnostic de repli de requête et l’analyse des colonnes calculées inutilisées. Un indice signale aussi les requêtes volumineuses analysées par sous-partie.

Corrigé