Niveau 6 · Dans la pratique

6.2Problèmes récurrents (playbook)

Objectif : disposer d'un playbook « symptôme → causes → actions » pour les problèmes de rapport courants.

Temps estimé : 12 min · Si vous n'avez que 5 min : lisez « L'essentiel en 30s » + le schéma.

L'essentiel en 30 secondes

Diagnostiquer : un symptôme = des causes probables = une séquence d'actions — on ne corrige pas au hasard.
Racines : jointures, niveau des résumés, filtrage serveur, tri avant cumul, gestion des nuls — 90 % des incidents.
Vérifier : recouper contre une valeur connue et tester sur un volume réel, pas seulement sur un échantillon.

Fil Farès — le tableau scotché à côté de l'écran

Farès garde ce tableau à côté de son écran à Alger. Verdict après un trimestre : trois lignes l'ont le plus servi — les totaux gonflés, le rapport très lent, et le solde progressif incohérent. Pour chacune, il a fini par appliquer la séquence (symptôme, causes, actions) au lieu de corriger au hasard.

Symptôme observé, causes vérifiées, actions dans l'ordre : le réflexe tient en trois temps.

Un réflexe par symptôme

La plupart des rapports faux ou lents échouent pour des raisons classiques. Relier chaque symptôme à ses causes probables et à une séquence d'actions fait gagner un temps précieux.

Symptôme	Causes probables	Actions
Les totaux sont gonflés / faux	doublons de jointure (un-à-plusieurs), mauvais niveau de résumé	vérifier les jointures (N0) ; recouper contre une valeur connue ; placer le résumé au bon niveau (N2.2)
Le rapport est très lent	filtrage côté client, tout rapatrié, sous-rapport dans les Détails	filtrer côté serveur (vérifier le SQL), ne prendre que les champs utiles, sous-rapport au niveau d'un groupe (N2.3, N5.4, N4.1)
Un solde progressif est incohérent	lignes non triées, réinitialisation mal réglée	trier avant (par date), régler le reset (jamais / par groupe) (N3.3)
Une formule échoue ou renvoie vide	valeur nulle non gérée, types incompatibles	tester IsNull avant, convertir (ToText/ToNumber), vérifier la syntaxe (N3.1, N3.4)
Le PDF déborde en largeur	trop de colonnes, orientation portrait	passer en paysage, réduire les colonnes, vérifier la zone imprimable (N5.1)
Groupes/lignes coupés entre deux pages	pas de « garder ensemble », sauts non gérés	Expert de section : garder ensemble, nouvelle page, supprimer les blancs (N2.5)
Un tableau croisé est illisible	champ à forte cardinalité en colonnes	peu de valeurs en colonnes, dimension nombreuse en lignes, regrouper plus grossièrement (N4.3)
Le graphique brouille le message	mauvais type, trop de catégories/séries	barres/courbe/secteurs selon le message, Top N, « Autres » (N4.2)
Le paramètre n'adapte pas le rapport	paramètre non intégré au filtre	l'intégrer à la sélection (« … = {?Param} »), côté serveur (N2.4)

Erreur d'interprétation fréquente : « le tableau remplace le diagnostic ». Non. Le tableau donne des causes probables, pas un verdict : observez le symptôme, vérifiez la cause (jointures, niveau des totaux, SQL serveur, tri, nuls), puis appliquez l'action ciblée.

Version texte du schéma (SEO / lecteurs d'écran / traduction) : Méthode du tableau : 1) Nommer le symptôme observé (totaux gonflés, lenteur, cumul incohérent, formule vide, PDF qui déborde, groupes coupés, cross-tab illisible, graphique confus, paramètre inopérant). 2) Retenir les causes probables du tableau sans conclure seul (jointures, niveau des résumés, filtrage client, tri, nuls, pagination, cardinalité, type de graphique). 3) Appliquer les actions dans l'ordre (N0, N2.2, SQL serveur N2.3, reset N3.3, IsNull N3.1/N3.4, paysage N5.1, garder ensemble N2.5, lignes vs colonnes N4.3, Top N N4.2, {?Param} N2.4). 4) Corriger à la racine (le même échec qui revient = un réflexe manquant). Leçon : un défaut qui revient appelle un réglage, pas des corrections au hasard.

Script prêt à dire — diagnostiquer sans corriger au hasard (30 s)

« Mon symptôme : [totaux gonflés / lenteur / cumul incohérent / formule vide / PDF qui déborde / paramètre inopérant]. Je vérifie la cause probable du tableau (jointures, niveau des totaux, SQL serveur, tri, IsNull), j'applique l'action ciblée et je recoupe contre une valeur connue. »

Modèle copier-coller — fiche incident rapport

Incident : [symptome observe].
Cause probable : [jointures / niveau resume / filtre client / tri / nuls / pagination].
Action : [verifier jointures N0 / deplacer resume N2.2 / filtre serveur N2.3 / reset cumul N3.3 / IsNull N3.1].
Recoupement : [total vs valeur connue] sur [volume reel].

TPE / petit budget

Pas de tableau formel : un symptôme, la cause probable, l'action et qui recoupe, notés.

PME Alger

Intégrer les réalités locales au diagnostic : volume réel de la base, poste d'impression PDF, référent connu.

Remote / hybride

Ajouter les traces écrites aux actions : à distance, un SQL vérifié et un chiffre de recoupement consignés évitent les doublons.

Interculturel

Expliciter les constats par écrit : ce qui semble évident (quel total, quel filtre) ne l'est pas pour tous.

Prudence : Rappel générique : un même échec qui revient n'est pas dix incidents — corrigez le réflexe à la racine (jointures, niveau des totaux, filtrage serveur, tri, gestion des nuls) et recoupez toujours avant de diffuser.

Défi 48h — appliquez demain

Repérez 1 symptôme actuel (totaux gonflés, lenteur, cumul incohérent), appliquez la ligne du tableau (symptôme nommé + cause vérifiée + action ciblée) et recoupez.

Checklist sortie de section

Je sais relier un symptôme à ses causes probables.
Je vérifie jointures, niveau des totaux et SQL serveur avant de corriger.
Je recoupe chaque total contre une valeur connue sur un volume réel.

Auto-évaluation 1-5 : diagnostic avant correction ?recoupement systématique avant diffusion ?

← Précédent : Cas concrets (V3)Suite : Bonnes pratiques & pièges (V3) →

Vérifiez votre compréhension

Les totaux de Farès sont gonflés. Quel réflexe applique le tableau ?

💡

Réflexe : diagnostiquer le symptôme, identifier la cause, appliquer l'action ciblée — ne pas corriger au hasard.