Versions concernées : BI 4.2, 4.3, BI 2025 · Temps de lecture : 9 min
En résumé. Web Intelligence propose trois façons de filtrer des données, qui n’agissent pas au même moment. Le filtre de requête agit avant le chargement : il devient une clause WHERE et réduit les lignes ramenées de la base. Le filtre de rapport agit après : il masque des lignes déjà chargées, dans un rapport, une section ou un bloc. Le contrôle d’entrée est un filtre de rapport interactif, manipulé par le lecteur. Choisir le mauvais mécanisme coûte en performance, en lisibilité ou en justesse des totaux.
Tableau comparatif
| Filtre de requête | Filtre de rapport | Contrôle d’entrée | |
|---|---|---|---|
| Moment | Avant le chargement (SQL) | Après le chargement | Après le chargement |
| Portée | Tout le document (le fournisseur) | Rapport, section ou bloc | Un ou plusieurs blocs, ou tout le rapport |
| Volume de données | Réduit | Inchangé | Inchangé |
| Interactif pour le lecteur | Via une invite (nécessite une actualisation) | Non (sauf barre de filtres) | Oui, instantané |
| Effet sur les totaux | Les totaux ne voient que les données filtrées | Les totaux du bloc suivent le filtre ; In Report ignore les filtres de bloc |
Idem filtre de rapport |
| Coût performance | Le plus faible | Recalcul du bloc | Recalcul à chaque clic |
| Cas d’usage | Périmètre : exercice, entité, statut | Vues fixes : « top 10 », un onglet par pays | Exploration par le lecteur |
La règle de choix en une phrase
Tout ce qui ne sera jamais affiché va dans un filtre de requête ; tout ce qui sert à présenter différemment les mêmes données va dans un filtre de rapport ; tout ce que le lecteur doit pouvoir changer sans actualiser va dans un contrôle d’entrée. Quand le lecteur doit changer le périmètre lui-même mais que le volume total est trop gros pour être chargé, la réponse est une invite sur un filtre de requête, pas un contrôle d’entrée.
Filtres de requête : ce qu’il faut savoir
- Invites : un filtre de requête dont la valeur est demandée à l’actualisation. Elles peuvent être obligatoires ou optionnelles, à valeur unique ou multiple, avec liste de valeurs ou saisie libre. Une invite optionnelle laissée vide est simplement ignorée dans le SQL.
- Filtres prédéfinis de l’univers : des conditions écrites une fois dans l’univers (« Exercice en cours », « Clients actifs ») et réutilisables partout. Ils garantissent une définition unique du périmètre dans toute l’organisation.
- Sous-requêtes et « résultats d’une autre requête » : pour filtrer une requête par les valeurs d’une autre (les clients qui ont commandé l’an dernier). Puissant, mais chaque niveau ajoute une passe SQL.
- Combinaisons ET / OU : l’imbrication se fait par glisser-déposer dans le panneau ; vérifiez toujours le SQL généré (Afficher le script), une parenthèse mal placée change silencieusement le périmètre.
- Filtrer sur une mesure : possible, mais le filtre devient une clause
HAVINGappliquée au niveau d’agrégation de la requête, pas du bloc affiché. « CA > 10 000 » ne signifie pas la même chose par client et par ligne de commande.
Le plus simple pour vérifier ce qu’on vient d’écrire est de regarder le SQL produit. Dans BI 2025, le Visualiseur du script de requête est la dernière icône de la barre d’outils de l’éditeur de requêtes — elle n’apparaît que pour une requête adossée à un univers, une source Excel ne générant pas de SQL. Deux filtres de requête posés sur des objets différents y ressortent sous la forme d’une clause WHERE unique, avec IN pour la liste de valeurs et AND entre les conditions.
WHERE, avec IN et AND. Le GROUP BY dit le reste : l’agrégat est calculé par la base, pas par Web Intelligence. Rien n’est ramené au poste qui ne soit déjà filtré et agrégé.Le GROUP BY mérite qu’on s’y arrête : c’est la base de données qui agrège, pas Web Intelligence. Rien n’est ramené au poste qui ne soit déjà filtré et agrégé — c’est toute la différence avec un filtre de rapport, qui masque des lignes déjà chargées. Au passage, le nom de table qui apparaît dans le FROM est souvent celui d’un agrégat pré-calculé choisi par l’univers en fonction des objets demandés : la couche sémantique ne se contente pas de traduire, elle oriente la requête vers la table la moins coûteuse.
Filtres de rapport : les trois niveaux
Un filtre de rapport peut être posé sur le rapport entier (tous les blocs de l’onglet), sur une section, ou sur un seul bloc. Les niveaux se cumulent en ET : un bloc filtré sur « France » dans un rapport filtré sur « 2026 » n’affiche que la France 2026. Deux formes existent :
- La barre de filtres (filtres simples) : rapide à poser, visible du lecteur, une valeur à la fois.
- Les filtres personnalisés : opérateurs complets (entre, différent de, correspond au modèle), plusieurs valeurs, filtres sur variables. C’est ici que l’on écrit « les 10 premiers » ou « écart < 0 ».
Point important : un filtre de rapport ne modifie pas le contexte de calcul. Sum([CA] In Report) continue de voir toutes les lignes chargées, même dans un bloc filtré, ce qui est exactement ce qu’il faut pour calculer une part du total. Pour qu’un calcul respecte un filtre, on utilise l’opérateur Where dans la formule (voir notre guide des contextes de calcul).
Contrôles d’entrée : le filtre côté lecteur
- Types : liste déroulante, boutons radio, cases à cocher, curseur simple ou double (pour les mesures), calendrier. Le choix se fait selon le nombre de valeurs et le type de l’objet.
- Affectation : un contrôle s’applique à un bloc, à plusieurs blocs choisis, ou à tout le rapport. C’est la source d’erreur numéro un : un contrôle qui ne filtre que le tableau, pas le graphique à côté.
- Dépendances : un contrôle peut dépendre d’un autre (région → pays → ville), ce qui réduit les listes à des valeurs cohérentes.
- Contrôles basés sur un bloc : un tableau ou un graphique peut lui-même servir de contrôle (« cliquer sur une barre filtre le reste du rapport »). C’est ce qui rapproche le plus Webi d’un tableau de bord natif.
- Valeurs par défaut et « Tout » : définissez-les explicitement ; un contrôle sans valeur par défaut affiche tout, ce qui masque son existence au lecteur.
Cinq pièges classiques
| Symptôme | Cause | Correction |
|---|---|---|
| Le rapport est lent alors qu’il n’affiche que 200 lignes | Le périmètre est posé en filtre de rapport, tout est chargé | Déplacer le filtre dans la requête |
| Le pourcentage du total change quand on filtre le bloc | Le dénominateur est calculé dans le contexte du bloc | Utiliser In Report ou In Block selon le besoin |
| Le contrôle d’entrée ne filtre pas le graphique | Affectation limitée au tableau | Modifier les dépendances du contrôle |
| Rien ne s’affiche après un filtre | Filtres cumulés rapport + section + bloc incompatibles | Ouvrir le panneau des filtres, vérifier chaque niveau |
| Le document s’actualise à chaque ouverture sans rien demander | Invite optionnelle + « actualiser à l’ouverture » | Rendre l’invite obligatoire, ou désactiver l’actualisation à l’ouverture |
Questions fréquentes
Peut-on combiner un contrôle d’entrée et un filtre de requête sur le même objet ?
Oui. Le filtre de requête fixe le périmètre maximal (par exemple les trois derniers exercices), le contrôle d’entrée laisse le lecteur choisir l’exercice à afficher parmi ceux chargés.
Un filtre de rapport peut-il porter sur une mesure ?
Oui, et il s’applique à la valeur agrégée dans le bloc : « CA > 10 000 » sur un tableau par client garde les clients dont le total dépasse 10 000. Le même filtre en requête porterait sur l’agrégation SQL, souvent différente.
Les contrôles d’entrée sont-ils conservés à l’enregistrement ?
La définition oui ; la sélection courante dépend de l’option d’enregistrement et de la version. Fixez une valeur par défaut si le rapport doit toujours s’ouvrir sur la même vue.
Un filtre de rapport change-t-il le résultat de Sum([CA] In Report) ?
Non pour un filtre de bloc ou de section ; oui pour un filtre au niveau du rapport entier, qui définit le périmètre « Report ».
Sources et références
- SAP Help Portal — Guide l’utilisateur SAP BusinessObjects Web Intelligence (BI 4.3 / 2025)
- SAP Community — Hub SAP BusinessObjects BI Platform
- Retours terrain Need4Viz sur des déploiements BI 4.1 à BI 2025
- Christian Ah-Soon (SAP), « SAP BI 2025: What’s New In Web Intelligence and Semantic Layer », SAP Community, mars 2025
👉 Découvrez Need4Viz et ce que nous apportons vraiment à SAP Web Intelligence
Need4Viz étend SAP Web Intelligence avec des capacités avancées de dataviz, d'interactivité, d'automatisation et d'IA pour transformer vos rapports en véritables outils de pilotage.
Découvrir Need4Viz