Accéder au contenu principal

Erreurs Excel courantes: les listes

Ayant du examiner d'innombrables tableaux Excel dans diverses organisations, je voudrais reprendre  quelques erreurs de design parmi les plus courantes. Je commencerai par les listes.

Une liste doit être en un seul bloc

Pour profiter des avantages d'Excel en matière de gestion de listes, celle-ci ne doivent pas comporter de "trous" entre les lignes, ni d'espace entre la ligne de titre et la suivante. Sans cela, tris, filtres, sous-totaux automatiques, et tableaux croisés dynamiques (Pivot tables) ne fonctionneront pas correctement.
Si vous voulez séparer visuellement le titre du reste du tableau, il suffit d'agrandir la hauteur de la ligne de titre.

Eviter les sous-totaux "manuels"

Excel comporte des options pour ajouter et retirer des sous-totaux dans une liste. Utiliser ces options évite les problèmes lors de tris ultérieurs. Ces options se trouvent dans le menu Data, Subtotals (Données, Sous-totaux).

Mettre le total général AU-DESSUS de la liste

Alors que nous sommes généralement habitués à mettre le total d'une colonne en bas de celle-ci, je trouve beaucoup plus pratique en Excel de mettre ces totaux EN HAUT de la colonne, au dessus des titres. Pourquoi ?
  • Cela permet de figer les 3 premières lignes de la feuille, et de se déplacer verticalement dans de longues listes tout en continuant à voir les titres ET les totaux.
  • Si on s'arrange pour que la formule de total de la colonne inclue un bon nombre de ligne vides, il suffira d'ajouter de nouvelles lignes en bas de la liste pour que ces lignes soit prises en compte. Avec un total en BAS de liste, il est nécessaire d'insérer des lignes et de vérifier qu'elle soit prise en compte dans le total
  • en cas de tri, le total n'est pas impacté ni déplacé

Commentaires

Posts les plus consultés de ce blog

Champs obligatoires dans un formulaire Access

Comment rendre des champs obligatoires dans un formulaire Access ? La réponse la plus évidente est de modifier le design de la table et d'assigner au paramètre Required la valeur True. L'ennui de cette méthode est que le message d'erreur d'Access n'est pas très convivial et ne spécifie pas quel champ a déclenché l'erreur. Plutôt que d'écrire une routine de gestion d'erreur complexe, il y a une solution toute simple: affecter la valeur Faux à la propriété  Required du champ, Validation Rule: Is Not Null Validation Text: le texte à afficher, ex: "Code Postal obligatoire" ..et le tour est joué. Cette astuce vient de l'excellent Allen Browne, dont le site (en anglais) regorge d'informations utiles sur Access. ps: je n'ai pas sous la main de version française d'Access pour la traduction des propriétés, désolé...

ROW_NUMBER OVER PARTITION en Access

Ceux qui ont l'habitude de travailler avec une "grosse" base données comme SQL Server / Oracle / PostGreSQL, sont parfois frustrés face à certaines lacunes du SQL d'Access.   Prenons par exemple: ROW_NUMBER() OVER PARTITION, dont l'absence rend certaines requêtes très compliquées.   J'ai donc écrit une petite fonction VBA qui peut être appelée depuis un query Access et qui simulera assez bien ce ROW_NUMBER() OVER PARTITION.   Notez que ceci ne fonctionnera pas correctement dans une vue ou un formulaire interactif. Par contre comme source d'un rapport ou d'un export Excel, c'est impeccable.   En pratique il est préférable d'initialiser la fonction avec une chaîne de caractères "improbable" avant de lancer le rapport, comme indiqué dans le code.