Piloter l’activité : données, tableaux de bord et processus

Une table exploitable contient une ligne par observation, une colonne par variable et une seule ligne d’en-têtes. Les cellules fusionnées, sous-totaux au milieu des données et valeurs mixtes compliquent les calculs. Gardez une copie des données source.

Pratique : Saisissez les trois lignes, transformez la plage en tableau et ajoutez une quatrième ligne de transport 2×35. Repérez une quantité volontairement saisie comme texte.

Une formule doit exprimer une règle métier compréhensible. Une référence relative se déplace quand on copie la formule ; une référence absolue conserve la cellule. Le symbole dollar permet de fixer colonne et/ou ligne.

Pratique : Créez les calculs sur quatre lignes, puis changez le taux à 5 %. Expliquez pourquoi les résultats évoluent sans modifier chaque formule.

Un résultat sans message d’erreur peut être faux. Les contrôles doivent vérifier le sens des données : quantités négatives, catégorie inconnue ou poste manquant. Masquer toutes les erreurs avec une valeur zéro peut cacher un problème.

Pratique : Introduisez trois anomalies : quantité 800, prix vide et catégorie « diverss ». Faites une feuille de contrôle qui les signale, puis corrigez depuis le brief.

Une synthèse doit répondre à une question : coût par catégorie, statut ou période. Un tableau croisé ne dispense pas de vérifier la plage source, le type de calcul et l’actualisation. Compter les lignes n’est pas sommer les montants.

Pratique : Construisez la synthèse, ajoutez une dépense accueil de 10 puis actualisez. Expliquez le passage à 400 et conservez la preuve.

Un budget utile sépare hypothèses, données, calculs et synthèse. Le prochain utilisateur doit savoir où saisir et ce qu’il ne doit pas écraser. Protéger une feuille évite certaines modifications accidentelles mais ne remplace pas le contrôle d’accès au fichier.

Pratique : Projet : livrez le budget complet avec huit tests et une note de cinq lignes expliquant total, réserve et principale dépense. Faites le vérifier par un autre lecteur.

Un tableau de bord fiable commence par des données définies : une ligne représente quoi, à quelle date et dans quelle unité ? Power Query conserve des étapes de transformation ; une correction manuelle isolée peut disparaître à l’actualisation.

Pratique : Importez trois lignes puis ajoutez une anomalie de type et un doublon. Définissez la règle de traitement et conservez le journal.

Une relation relie des tables par des clés. Une clé non unique du côté attendu peut produire des doublons et des calculs trompeurs. Le grain de chaque table doit être explicite.

Pratique : Dessinez le modèle puis créez deux tables liées. Testez une clé inconnue et une clé dupliquée. Expliquez leur effet.

Une mesure est évaluée dans un contexte de filtre. Un total peut différer de la somme de ratios affichés, notamment pour une moyenne ou un taux. Il faut définir l’indicateur avant d’écrire la formule.

Pratique : Créez total, nombre et moyenne. Filtrez une catégorie et expliquez le changement. Ajoutez un groupe de taille différente pour tester le piège des moyennes.

Un écran doit répondre à une question précise. Trop de visuels et des axes trompeurs rendent la lecture difficile. Les couleurs doivent avoir une signification stable et rester lisibles.

Pratique : Créez une page avec trois cartes, un graphique et une table. Testez deux filtres et le cas sans résultat.

Un rapport local et un rapport partagé n’ont pas les mêmes contraintes. Vérifiez licences, accès et règles de confidentialité avant diffusion. Une actualisation doit être testée et surveillée.

Pratique : Projet : livrez modèle, mesures, rapport, dictionnaire et huit tests. Expliquez une anomalie de total et sa correction au formateur.

Une accumulation de pages ne constitue pas un système de travail. Définissez ce que l’équipe doit retrouver : tâches, responsables, échéances et décisions. Séparez documentation stable et suivi opérationnel.

Pratique : Dessinez l’arborescence et créez un espace de test avec trois pages. Faites retrouver une décision à un autre lecteur.

Une base rassemble des éléments dotés des mêmes propriétés. Le titre identifie la tâche ; statut, responsable et échéance permettent le suivi. Une propriété doit servir un usage, pas seulement enrichir la fiche.

Pratique : Saisissez six tâches dont deux sans responsable. Repérez les informations manquantes puis complétez avec des personnes fictives.

Une vue montre la même base avec un filtre, un tri ou une présentation différente. Copier les tâches dans plusieurs bases peut créer des versions contradictoires. Une relation relie des éléments de bases distinctes lorsqu’un vrai besoin le justifie.

Pratique : Construisez trois vues et faites varier le statut et la date de deux tâches. Notez les résultats attendus puis observés.

Une page facile à partager peut exposer plus que prévu. Les droits doivent être testés depuis le point de vue du destinataire. Un lien public n’est pas un mécanisme de confidentialité.

Pratique : Préparez une matrice équipe/prestataire/public. Testez deux rôles et rédigez une procédure de retrait d’accès en fin de projet.

Un outil sans routine devient rapidement obsolète. Définissez quand mettre à jour, qui arbitre et comment archiver. La qualité de la base dépend de règles communes comprises par l’équipe.

Pratique : Projet : livrez espace, six tâches, trois vues, matrice d’accès et guide d’une page. Animez une revue simulée de dix minutes.

Une automatisation transforme des données entre applications. Un déclencheur démarre le scénario ; les actions produisent des effets. Un flux utile a une entrée définie, une sortie vérifiable et une stratégie en cas d’échec.

Pratique : Rédigez le contrat de données de R001 et trois cas limites : email absent, quantité nulle, identifiant déjà présent.

Le mapping associe une valeur source à un champ cible. Deux champs qui ont un nom proche ne sont pas nécessairement équivalents. Vérifiez les données réelles d’un essai, leur type et leur format.

Pratique : Construisez le trajet R001 vers un tableau de test. Ajoutez R002 avec une quantité différente et vérifiez chaque colonne.

Un filtre décide si un élément continue. Un routeur répartit les traitements ; ses branches peuvent nécessiter des conditions exclusives. Sans branche de revue, une demande invalide peut disparaître silencieusement.

Pratique : Ajoutez les filtres et exécutez six entrées fictives. Comptez les issues : le total des entrées doit être expliqué par les sorties et les revues.

Rejouer un scénario peut reproduire ses effets. L’idempotence signifie qu’un même événement ne crée pas plusieurs résultats indésirables. Une clé métier stable permet de reconnaître une demande déjà traitée. Les gestionnaires d’erreurs doivent être choisis selon l’effet déjà réalisé.

Pratique : Provoquez une destination indisponible dans le test. Réparez puis rejouez. Remettez le journal avant/après et le nombre de lignes R001.

Une automatisation n’est pas terminée quand un seul test réussit. Il faut couvrir les erreurs, les changements de champs et le départ du gestionnaire. Le propriétaire doit comprendre comment arrêter et reprendre le traitement.

Pratique : Projet : livrez le flux formulaire → tableau → brouillon avec huit tests, dont doublon, erreur de destination et champ absent. Faites une démonstration à une personne qui n’a pas construit le flux.

Les possibilités de Copilot dépendent du produit, de la licence, des applications et des réglages de l’organisation. Un nom commercial proche ne signifie pas que toutes les fonctions sont incluses. Les permissions sur les documents restent un point central.

Pratique : Créez une matrice document/rôle/accès attendu. Comparez deux comptes de test autorisés ou rédigez le protocole si vous ne disposez pas du second compte.

Une consigne utile fixe objectif, contexte, sources et résultat attendu. Demander une note à partir d’un document précis limite le périmètre, sans garantir l’absence d’erreur. Le contrôle humain reste nécessaire.

Pratique : Produisez une note de 150 mots et un email de 80 mots à partir du même brief. Annotez chaque fait avec sa source.

Une synthèse utile distingue décisions, actions, responsables et échéances. Une transcription ou un compte rendu peut contenir des erreurs ; il faut revenir à la source autorisée. Le résumé ne remplace pas l’accord des participants.

Pratique : Rédigez le tableau puis injectez volontairement une erreur d’échéance. Demandez une comparaison et vérifiez vous-même la correction.

Une présentation doit préserver le sens tout en réduisant la quantité de texte. Un graphique généré peut être plausible mais non fondé. Les données et illustrations doivent être contrôlées avant projection.

Pratique : Produisez cinq slides et les notes orales. Faites lire les titres seuls à un collègue : l’histoire doit rester compréhensible.

Chaque transformation peut perdre une nuance. Un contrôle final doit comparer l’ensemble au dossier initial, pas seulement chaque fichier au précédent. Le temps de relecture entre dans le bilan de productivité.

Pratique : Projet : remettez dossier fictif, note, email, cinq slides et journal des contrôles. Expliquez une erreur détectée et la façon d’éviter sa répétition.