La performance d'un rapport se joue avant tout sur la QUANTITÉ de données rapatriées et sur ce qui est exécuté CÔTÉ BASE plutôt que sur le poste — voici les leviers, du plus important au plus fin. Le principe central : un rapport est lent principalement quand il RAPATRIE trop de données et fait trop de traitement CÔTÉ CLIENT (sur le poste). La clé est de minimiser les données transférées et de POUSSER le travail vers la base (optimisée pour cela). Les leviers, par ordre d'impact : (1) FILTRER CÔTÉ SERVEUR (le levier n°1). La sélection des enregistrements doit être poussée à la base (traduite en clause WHERE) pour que la base ne renvoie QUE les données filtrées, pas toute la table. Formulez des conditions SIMPLES sur les champs de la base (pas sur des formules complexes), et VÉRIFIEZ le SQL généré (« Show SQL Query ») : votre filtre doit apparaître dans le WHERE. Un filtrage client (tout rapatrier puis filtrer) est catastrophique sur gros volumes. (2) Ne rapatrier que le NÉCESSAIRE. Ne sélectionnez que les TABLES et CHAMPS utiles (pas toute la base, pas des colonnes inutilisées). Moins de données = plus rapide. Limitez aussi le nombre d'enregistrements au strict besoin. (3) POUSSER le regroupement et les agrégations à la BASE. Activez « Perform Grouping On Server » quand c'est possible, ou utilisez une COMMANDE SQL qui agrège côté base (SUM, GROUP BY en SQL) — la base renvoie alors des totaux, pas des milliers de lignes de détail à agréger sur le poste. (4) Exploiter les INDEX. Filtrez et joignez sur des champs INDEXÉS dans la base — les index accélèrent énormément la sélection et les jointures. (5) Soigner les JOINTURES. Des jointures propres (sur des clés indexées) et le bon type évitent des produits cartésiens et des volumes explosifs. (6) Attention aux SOUS-RAPPORTS liés. Placés dans la section Détails, ils s'exécutent une fois PAR LIGNE (désastreux sur gros volumes) — placez-les au niveau d'un GROUPE (une fois par groupe), filtrez-les, allégez-les. Envisagez une alternative (jointure, commande SQL) quand possible. (7) Limiter les formules CÔTÉ CLIENT. Des filtres/calculs basés sur des formules Crystal complexes forcent le traitement local ; privilégiez les opérations que la base peut faire. (8) Réduire les objets lourds (nombreux sous-rapports, graphiques) et la complexité inutile. Les bonnes pratiques de test : (1) TESTEZ sur un VOLUME RÉALISTE (production), pas seulement sur un échantillon : un rapport rapide sur 100 lignes peut s'effondrer sur 1 million. (2) Mesurez le temps d'exécution et identifiez le goulot (rapatriement ? traitement local ? sous-rapports ?). (3) Vérifiez le SQL généré pour confirmer que filtres/regroupements sont côté serveur. La règle d'or : minimiser les données rapatriées + maximiser le travail fait CÔTÉ BASE. En résumé : rendez un rapport performant en FILTRANT CÔTÉ SERVEUR (levier n°1 — vérifier le SQL), en ne rapatriant que les tables/champs/enregistrements NÉCESSAIRES, en POUSSANT regroupements et agrégations à la base (options serveur, commande SQL), en exploitant les INDEX et des jointures propres, et en maîtrisant les sous-rapports liés (au niveau d'un groupe, pas des détails). Évitez les formules complexes qui forcent le traitement client. Testez sur un volume réel. La performance dépend surtout de la quantité de données transférées et de ce qui est exécuté côté base vs côté poste — optimiser cela est ce qui rend un rapport utilisable sur de gros volumes, un enjeu majeur en production.

Un rapport professionnel repose sur quatre piliers — JUSTESSE, LISIBILITÉ, RÉUTILISABILITÉ, MAINTENABILITÉ — plus la performance, et ces principes dépassent Crystal Reports (ils valent pour tout reporting). Voici l'essentiel. (1) JUSTESSE (le plus important — un rapport faux est pire qu'absent). Un rapport doit dire la VÉRITÉ ; un rapport joli mais faux trompe et peut mener à de mauvaises décisions. (a) Vérifiez les JOINTURES — le piège n°1 : de mauvaises jointures créent des DOUBLONS qui gonflent les totaux, ou font disparaître des lignes. Comprenez le modèle de données, vérifiez les liens et les types de jointure. (b) RECOUPEZ les totaux contre des valeurs CONNUES (un total attendu, un chiffre de référence) pour détecter les erreurs. (c) Gérez les valeurs NULLES (IsNull) pour éviter des calculs faux ou des formules qui échouent. (d) Testez avec des données réelles. La justesse prime sur tout le reste. (2) LISIBILITÉ (un rapport doit COMMUNIQUER clairement). (a) Mise en forme COHÉRENTE et SOBRE (mêmes styles pour les mêmes rôles, peu de polices/couleurs, hiérarchie claire). (b) Colonnes ALIGNÉES, nombres bien FORMATÉS (décimales, séparateurs, alignés à droite), dates au bon format. (c) Structure CLAIRE (sections bien utilisées, groupes logiques, titres, totaux mis en évidence). (d) Pagination maîtrisée (pas de débordement, sauts propres, en-têtes répétés). (e) Adapter le niveau de détail (synthèse vs détail). (3) RÉUTILISABILITÉ (un rapport durable sert de multiples cas). (a) PARAMÈTRES pour un rapport GÉNÉRIQUE (un seul modèle pour toutes les périodes/clients au lieu d'un rapport par cas). (b) FORMULES réutilisables, décomposées. (c) MODÈLES de rapport d'entreprise (mise en forme, cartouche, logo standardisés) pour la cohérence entre rapports. (d) Listes de valeurs dynamiques (à jour). (4) MAINTENABILITÉ (un rapport qu'on peut faire évoluer). (a) NOMMEZ clairement formules et paramètres (pas « Formule1 »). (b) DOCUMENTEZ la logique complexe (commentaires, description). (c) DÉCOMPOSEZ les formules complexes en plusieurs formules simples. (d) ÉVITEZ la sur-complexité (une commande SQL alambiquée, dix sous-rapports imbriqués — difficile à maintenir). (e) Structurez proprement pour qu'un autre (ou vous, plus tard) comprenne le rapport. (5) PERFORMANCE (voir la question dédiée) : filtrer côté serveur, ne rapatrier que le nécessaire, pousser le travail à la base — surtout sur gros volumes. (6) ADAPTER au PUBLIC et à l'USAGE : synthèse pour la direction, détail pour l'opérationnel ; bon format d'export (PDF pour lire, Excel pour analyser) ; interactivité (drill-down) pour l'écran. (7) TESTER avant de diffuser : justesse (totaux recoupés), mise en page (aperçu, PDF), performance (volume réel). Ne diffusez jamais un rapport non testé. Le principe qui dépasse l'outil : ces bonnes pratiques valent pour TOUT reporting (Crystal, Power BI, autre) — ce sont des compétences de conception d'états et de communication de données, transférables. La maîtrise technique de Crystal Reports est nécessaire, mais c'est l'application de ces principes qui fait la différence entre un rapport « techniquement produit » et un rapport « juste, clair, performant et utile ». En résumé : un rapport professionnel est JUSTE (jointures vérifiées, totaux recoupés, nuls gérés — la priorité absolue, un rapport faux trompe), LISIBLE (mise en forme cohérente/sobre, colonnes alignées, nombres formatés, structure claire, pagination maîtrisée), RÉUTILISABLE (paramètres, modèles, formules réutilisables), MAINTENABLE (nommer, documenter, décomposer, éviter la sur-complexité) et PERFORMANT (côté serveur, volume minimal), adapté au public/usage et TESTÉ sur données réelles avant diffusion. Ces principes dépassent Crystal Reports. Le but ultime n'est pas de « maîtriser l'outil » mais de produire des états JUSTES, CLAIRS, PERFORMANTS et UTILES — la maîtrise technique au service de l'information fiable et exploitable fait le concepteur d'états professionnel. Rappelez-vous : un bon rapport est d'abord JUSTE et CLAIR, puis rapide.