Pièges et bonnes pratiques de la conduite de projet (synthèse transverse)

Vous disposerez d'un catalogue de 57 pièges classés en six familles, chacun avec symptôme, cause, remède et renvoi vers le fichier qui le traite en profondeur.

Guide≈ 18 min de lectureVérifiéLecture

En bref

Vous disposerez d'un catalogue de 57 pièges classés en six familles, chacun avec symptôme, cause, remède et renvoi vers le fichier qui le traite en profondeur.
Vous aurez 34 bonnes pratiques numérotées, utilisables comme principes d'équipe.
Vous pourrez lancer un projet avec la checklist de démarrage et le relire avec la checklist de revue (trimestrielle ou en comité).
Vous aurez une section dédiée aux projets data / BI / datamart, où la plupart des pièges sont aggravés par la nature de la donnée (irréversibilité, volumétrie, exactitude).

Ce fichier synthétise et ne remplace pas les fichiers de fond : chaque piège renvoie vers le chapitre qui l'explique. Les notes /5 sont des appréciations d'expert (voir NOTATION) pour une équipe de 4 à 12 personnes, projet BI/datamart de 6 à 18 mois.

Sur cette page

1. Comment lire ce catalogue
2. Famille A : cadrage, valeur et périmètre
3. Famille B : méthode et organisation
4. Famille C : estimation, planification et pilotage
5. Famille D : équipe, parties prenantes et communication
6. Famille E : qualité, livraison et exploitation
7. Famille F : spécificités data, BI et datamart
8. Les 34 bonnes pratiques
9. Checklist de démarrage de projet
10. Checklist de revue de projet
11. Checklist spéciale projet data
12. Gravité et fréquence : où concentrer ses efforts
13. Voir aussi

Niveau : 🟢→🔴

1. Comment lire ce catalogue#

🟢 Novice — un piège, c'est quoi ?#

Un piège est une erreur qui paraît raisonnable sur le moment et dont les effets arrivent tard. On les reconnaît à leur symptôme (ce qu'on observe), on les comprend par leur cause (le mécanisme), on les traite par un remède (l'action qui change la situation). Les pièges se combinent : un cadrage flou (A1) fabrique des estimations fantaisistes (C1) qui nourrissent un planning irréaliste (C3), qui produit une qualité sacrifiée (E1).

🟡 Pratique — format#

Chaque ligne : ID | Piège | Symptôme | Cause | Remède | Pour approfondir. L'ID (A1…F15) permet de s'y référer en rétrospective (« on est en train de faire le piège C4 »). Les liens renvoient vers Fondamentaux, Scrum en pratique, Scrum et data, Méthodes prédictives, Méthodes agiles et lean, Méthodes spécifiques data, Choisir et hybrider, CI/CD, CI/CD pour la data, IA et conduite de projet.

🔴 Expert — pourquoi catalogue plutôt que recette#

Aucune méthode ne protège de tous les pièges ; elles déplacent les risques. Le prédictif expose au piège du changement tardif ; l'agile au piège de l'absence de vision ; le « tout-outil » au piège de la forme sans le fond. L'expertise consiste à connaître les modes de défaillance de la méthode choisie et à y mettre des garde-fous ciblés (voir Comparatif des méthodes). Ce catalogue est donc à lire contre la méthode en usage : quels pièges la vôtre favorise-t-elle ?

2. Famille A : cadrage, valeur et périmètre#

ID	Piège	Symptôme	Cause	Remède	Approfondir
A1	Objectif flou	Chacun décrit le projet autrement ; débats sans fin sur « ce qui est dans le périmètre »	Cadrage bâclé, sponsor absent	Phrase d'objectif + critères de succès mesurables validés par écrit	Fondamentaux
A2	Solution avant problème	On choisit l'outil (ou la techno) avant de formuler le besoin	Effet de mode, pression commerciale	Décrire le problème et la valeur attendue d'abord ; l'outil est une conclusion	Fondamentaux
A3	Valeur jamais mesurée	Livré à l'heure, personne ne l'utilise	Succès défini par la livraison, pas par l'usage	Définir un indicateur d'adoption ou de bénéfice, le suivre après livraison	Fondamentaux
A4	Dérive de périmètre (scope creep)	Chaque semaine une « petite demande »	Pas de mécanisme d'arbitrage	Backlog unique, PO décideur, ajout = retrait ou report	Scrum en pratique
A5	Sponsor fantôme	Décisions qui traînent, blocages non levés	Sponsor nommé mais non engagé	Rituel court de pilotage avec décisions datées ; escalade définie	Fondamentaux
A6	Exigences figées trop tôt	Spécifications de 200 pages obsolètes à la livraison	Prédictif appliqué à un besoin incertain	Cadrer l'incertitude (spike, prototype), découper, valider tôt	Méthodes prédictives
A7	Exigences jamais écrites	Dispute sur ce qui était demandé	Confiance excessive à l'oral	Critères d'acceptation écrits, validés, versionnés	Scrum en pratique
A8	Cas d'affaires d'un jour	Le budget est annulé en cours de route	Hypothèses de bénéfice non revues	Revoir le cas d'affaires à chaque jalon ; arrêter est une décision légitime	Fondamentaux

⚠️ Piège

Symptôme : le projet « réussit » au sens du plan mais le métier continue d'utiliser son tableur. Cause : on a livré ce qui était demandé, pas ce qui était nécessaire (A3 + A7). Remède : mesurer l'usage à 30 et 90 jours, et inclure un utilisateur réel dans l'équipe de recette dès le début.

3. Famille B : méthode et organisation#

ID	Piège	Symptôme	Cause	Remède	Approfondir
B1	Méthode importée sans contexte	« Chez nous ça ne marche pas »	Copie d'un modèle (Spotify, SAFe) sans adaptation	Partir du problème, pas du cadre ; expérimenter et inspecter	Agiles et lean
B2	Cérémonies sans empirisme	Dailies de statut, rétros sans action, reviews sans retours	Rituels appliqués par habitude	Réaffirmer l'objectif de chaque événement ; supprimer ce qui n'inspecte rien	Scrum cadre
B3	ScrumBut permanent	« On fait du Scrum, mais… » pour tout	Adaptations non assumées	Nommer les écarts, en évaluer le coût, les assumer ou les corriger	Scrum en pratique
B4	Wagile non maîtrisé	Cadrage cascade, développement en sprints, recette finale tardive	Gouvernance prédictive collée sur exécution agile	Livrer des incréments recettables ; recette continue	Choisir et hybrider
B5	Agile = pas de plan	Pas de vision, pas de roadmap, tout est « émergent »	Confusion entre adaptation et improvisation	Product Goal, roadmap par objectifs, plan révisé régulièrement	Scrum cadre
B6	Prédictif = changement interdit	Les changements deviennent des conflits contractuels	Contrat et gouvernance rigides	Clauses de variation, réserve de gestion, jalons de réévaluation	Méthodes prédictives
B7	Sur-processus	Plus de temps à documenter le projet qu'à le faire	Méthode surdimensionnée	Ajuster la cérémonie à la taille et à la criticité	Comparatif des méthodes
B8	Changement de méthode brutal	Équipe désorientée, productivité en chute	Passage en une fois à un nouveau cadre	Trajectoire progressive, coaching, indicateurs de transition	Choisir et hybrider
B9	PO « boîte aux lettres »	Les décisions remontent à un comité, vélocité bloquée	Product Owner sans pouvoir	Mandat clair, disponibilité, accès au sponsor	Scrum cadre

4. Famille C : estimation, planification et pilotage#

ID	Piège	Symptôme	Cause	Remède	Approfondir
C1	Estimation = engagement	Une fourchette devient une promesse ferme	Confusion prévision/engagement	Donner des fourchettes, les nommer, séparer cible et prévision	Scrum en pratique
C2	Estimation par l'absent	Chiffrage fait par un chef sans l'équipe	Désir de rapidité	Estimation collective, avec ceux qui réaliseront	Scrum en pratique
C3	Planning sans marge	Tout glisse au premier aléa	Optimisme, loi de Hofstadter	Marges explicites, scénario pessimiste, jalons de contrôle	Fondamentaux
C4	Vélocité comme objectif	Les points gonflent, la valeur stagne	Mesure transformée en cible (Goodhart)	Utiliser la vélocité en prévision interne, jamais comme performance	Scrum en pratique
C5	Comparer les équipes	Compétition sur les points, tricherie	Management par indicateur	Comparer des tendances propres à chaque équipe, pas des niveaux	Scrum en pratique
C6	Burndown rassurant	La courbe descend, la livraison échoue	Mesure du travail fait, pas de la valeur livrée	Suivre le flux et les incréments recettés	Scrum en pratique
C7	Dépendances oubliées	Blocage d'une livraison par une source ou une autre équipe	Cartographie absente	Cartographier tôt, traiter la dépendance comme un item suivi	Scrum et data
C8	Multitâche et surcharge	Tout est « en cours », rien n'est terminé	Pas de limite du travail en cours	Limiter le WIP, finir avant de commencer	Agiles et lean
C9	Pilotage par statut vert	Tout est vert jusqu'à l'explosion (effet « pastèque »)	Peur de signaler un problème	Culture du signal faible, critères objectifs de couleur	Fondamentaux
C10	Données de pilotage fausses	Tableaux de bord incohérents	Saisie après coup, définitions divergentes	Définitions communes, alimentation automatique depuis l'outil	Métriques et reporting

5. Famille D : équipe, parties prenantes et communication#

ID	Piège	Symptôme	Cause	Remède	Approfondir
D1	Héros et point unique de défaillance	Un départ paralyse le projet	Savoir concentré chez une personne	Binômes, revues croisées, documentation vivante, rotation	Scrum en pratique
D2	Insécurité psychologique	Personne ne signale de problème	Sanction du messager	Réagir à une mauvaise nouvelle par un remerciement ; traiter les causes	Fondamentaux
D3	Parties prenantes oubliées	Opposition découverte à la livraison	Cartographie absente	Cartographie dès le cadrage, plan de communication minimal	Fondamentaux
D4	Communication par e-mail	Décisions perdues, versions concurrentes	Absence de lieu de vérité	Décisions consignées dans un registre unique	Scrum en pratique
D5	Équipe en silos	Chaque rôle travaille en séquence, remises de patate chaude	Organisation par fonction	Équipe pluridisciplinaire et incréments verticaux	Scrum et data
D6	Équipe à temps partiel dilué	Chacun à 20 % sur cinq projets	Allocation par « fractions »	Allocation stable, peu de projets par personne	Scrum en pratique
D7	Résistance au changement ignorée	Outil livré, non adopté	Conduite du changement absente	Impliquer les utilisateurs, former, mesurer l'adoption	Matrice projet data : adoption
D8	Usage de l'IA sans cadre	Fuites de données, textes non relus	Adoption spontanée sans charte	Charte d'usage, outil encadré, relecture	IA et conduite de projet

6. Famille E : qualité, livraison et exploitation#

ID	Piège	Symptôme	Cause	Remède	Approfondir
E1	Qualité sacrifiée au délai	Dette qui ralentit chaque Sprint suivant	Pression de calendrier, DoD absente	Definition of Done non négociable, dette tracée au backlog	Scrum cadre
E2	Recette en fin de projet	Défauts massifs découverts tard	Test repoussé en phase finale	Tester en continu ; recette par incréments	Méthodes prédictives
E3	Livraison manuelle	Déploiements différents d'un environnement à l'autre	Procédure orale, scripts personnels	Pipeline reproductible, promotion entre environnements	CI/CD
E4	Tests qui ne testent rien	Verts en permanence, défauts en production	Tests sans assertion utile, couverture cosmétique	Tests sur comportements, mutation ou revue, non-régression chiffrée	CI/CD
E5	Pas de retour arrière prévu	Un déploiement raté dure des heures	Rollback jamais répété	Plan de retour répété, marche arrière ou avance définie	CI/CD
E6	« Terminé » sans exploitation	Livré mais non supervisé, non documenté	Exploitation hors champ	Exploitation dans la DoD ; transfert au run préparé	CI/CD
E7	Environnements divergents	« Ça marche chez moi »	Pas de parité	Infrastructure décrite en code, parité mesurée	CI/CD

7. Famille F : spécificités data, BI et datamart#

Dans un projet data, la donnée n'est pas rejouable par construction, ses défauts se propagent en silence, et son exactitude est le produit. D'où une famille à part.

ID	Piège	Symptôme	Cause	Remède	Approfondir
F1	Qualité des sources sous-estimée	Chiffres faux, rapprochements impossibles	Pas de profilage avant conception	Profilage et spike de données dès le cadrage	Scrum et data
F2	Jeu de test « jouet »	Tout passe sur 1 000 lignes, tout échoue sur 100 millions	Volumétrie non testée	Tests de volumétrie, mesures de temps en pipeline	CI/CD pour la data
F3	Traitement non idempotent	Doublons ou écarts après rejeu	Pas de conception pour le rejeu	`MERGE`/purge ciblée, clés déterministes, double exécution testée	CI/CD pour la data
F4	Historisation oubliée	Impossible de reproduire un chiffre passé	Dimensions écrasées (type 1) sans réflexion	Décider type 1/2 par attribut ; tester la reproductibilité	Méthodes data
F5	Définitions métier divergentes	Deux rapports, deux « chiffres d'affaires »	Pas de glossaire ni de couche sémantique unique	Définition unique validée, mesure unique dans le modèle	Matrice projet data : gouvernance
F6	Recette métier sautée	Chiffres contestés après mise en production	Recette limitée à « le rapport s'affiche »	Protocole de recette sur chiffres, rapprochements, validation écrite	Scrum et data
F7	Dérive silencieuse des sources	Colonne renommée ou type changé en amont, rapports vides	Aucun contrat de données	Contrats de données, contrôles de schéma, alerte	CI/CD pour la data
F8	Rollback « impossible »	Une donnée corrompue est déjà propagée	Pas de sauvegarde ni de réversibilité	Instantanés, déploiements additifs, rejeu depuis la source	CI/CD pour la data
F9	Données personnelles en test	Copie de production dans les environnements de test	Commodité	Anonymisation, jeux synthétiques, droits de production limités	Matrice projet data : sécurité
F10	Sécurité et RLS oubliées	Un utilisateur voit les chiffres d'un autre périmètre	Sécurité traitée en fin de projet	Droits dans les critères d'acceptation, tests par rôle	Matrice BI : RLS
F11	Rapport « pixel-parfait » sur modèle bancal	Beaux écrans, mesures fausses	Priorité à la visualisation	Modèle et mesures d'abord, visuel ensuite	Matrice BI : modèle sémantique
F12	Renommage de colonne en cascade	Rapports clients cassés	Pas d'analyse d'impact	Lineage, dépréciation progressive, versions de modèle	Matrice projet data : métadonnées
F13	Chargement total à chaque fois	Fenêtre de traitement qui explose avec le volume	Pas de stratégie incrémentale	Chargement incrémental, partitionnement, mesure continue	Matrice BI : performance
F14	Dépendance à une personne clé	Le seul qui connaît le modèle est absent	Savoir non documenté	Documentation dérivée du schéma, revue croisée	Matrice projet data : métadonnées
F15	Migration de données traitée comme un copier-coller	Pertes, doublons, écarts non expliqués	Absence de réconciliation	Réconciliation à chaque étape, rejeux répétés avant la bascule	Méthodes data

🧪 Exemple

Un datamart SFA alimenté chaque nuit : la source ajoute une colonne et change le type d'une autre. Le chargement ne plante pas (conversion implicite), mais les montants sont tronqués. Pièges combinés : F7 (pas de contrat), F6 (la recette n'a rien comparé), F8 (la donnée fausse est déjà consommée). Parade : contrôle de schéma bloquant en entrée, rapprochement de totaux en sortie, et possibilité de rejouer la veille.

Au total : A (8) + B (9) + C (10) + D (8) + E (7) + F (15) = 57 pièges répertoriés.

8. Les 34 bonnes pratiques#

Regroupées par intention. Chacune est un principe vérifiable, pas un slogan.

🟢 Novice — les fondations#

Écrire l'objectif en une phrase et les critères de succès avec des nombres (ou des observations vérifiables).
Nommer un sponsor et un décideur de produit (PO) disponibles, avec un mandat réel.
Cartographier les parties prenantes avant d'écrire le premier ticket.
Définir « terminé » (DoD) collectivement, et la respecter.
Limiter le travail en cours : terminer avant de commencer.
Livrer petit et souvent : des incréments recettables à intervalle régulier.
Tenir un registre unique des décisions et des risques, daté, avec des responsables.
Rendre le travail visible : un tableau que tout le monde lit, alimenté sans effort.

🟡 Pratique — le quotidien#

Estimer en fourchettes, collectivement, et distinguer prévision et engagement.
Prévoir par le flux (temps de cycle, débit) dès que l'historique existe.
Raffiner le backlog en continu, et en garder peu de « prêt » (la qualité vaut mieux que le volume).
Découper en tranches verticales (de la source au rapport), pas en couches techniques.
Traiter la dette explicitement : ticket, estimation, quota régulier de capacité.
Faire des rétrospectives qui produisent une à trois actions suivies jusqu'à leur clôture.
Prévoir des marges et un scénario pessimiste dans tout plan engageant.
Mettre en place une revue de code et de scripts SQL systématique, y compris pour le travail assisté par IA.
Automatiser le déploiement et le rendre identique d'un environnement à l'autre (CI/CD).
Tracer chaque livrable : ticket, version, auteur, relecteur (traçabilité par défaut).
Mesurer l'usage après la livraison, pas seulement la livraison.
Documenter ce qui peut être dérivé automatiquement (schéma, notes de version) et régénérer à chaque version.

🔴 Expert — la maturité#

Choisir la méthode par dimension (taille, incertitude, réglementation, contrat, maturité, nature data) plutôt que par mode (Choisir et hybrider).
Connaître les modes de défaillance de sa méthode et y placer des garde-fous ciblés.
Réduire les dépendances plutôt que les coordonner : équipes alignées sur les flux de valeur.
Utiliser le coût du retard pour prioriser, pas l'intuition du plus bruyant (Fondamentaux).
Retarder les décisions irréversibles et acheter des options (spikes, prototypes) tant que l'incertitude est haute.
Mesurer le flux (DORA et équivalents) pour apprendre, jamais pour classer des personnes.
Traiter les indicateurs comme des hypothèses : si une mesure devient une cible, la remettre en cause (Goodhart).
Cultiver la sécurité psychologique : une mauvaise nouvelle annoncée tôt est un succès de l'équipe.
Faire de l'IA un contradicteur, pas un décideur, avec charte, garde-fous et mesure du gain (IA et conduite de projet).
Concevoir pour le rejeu et la réversibilité : idempotence, instantanés, déploiements additifs (CI/CD pour la data).
Gérer les contrats de données et les versions de modèle comme des interfaces publiques.
Faire valider les chiffres par le métier, sur un protocole écrit et des rapprochements reproductibles.
Séparer le run du build en nommant explicitement ce qui passe à l'exploitation et à quelle condition.
Revoir la méthode tous les trimestres : ce qui servait à 5 personnes peut gêner à 12.

✅ Bonne pratique

Une bonne pratique n'est bonne que dans un contexte. Pour chacune, demandez : quel problème résout-elle chez nous aujourd'hui ? Si la réponse est « aucun », ne l'appliquez pas (piège B7).

9. Checklist de démarrage de projet#

À passer en revue avant le premier sprint ou la première phase. Toute case à « non » est un risque à nommer, pas forcément un blocage.

Valeur et cadrage

[ ] Une phrase d'objectif écrite et partagée.
[ ] Des critères de succès observables (usage, bénéfice) et non seulement de livraison.
[ ] Un sponsor identifié, disponible, qui connaît ses obligations.
[ ] Un périmètre « dedans / dehors » écrit.
[ ] Un cas d'affaires, même sommaire, et la règle de sa revue.

Organisation

[ ] Un décideur de produit (PO ou équivalent) avec un mandat.
[ ] Une équipe nommée, allocation stable et rôles clairs (MOA/MOE précisés).
[ ] Une méthode choisie et justifiée au regard du contexte (Choisir et hybrider).
[ ] Une Definition of Done et, facultativement, une Definition of Ready (pratique courante, absente du Scrum Guide).
[ ] Un lieu unique pour le backlog, les décisions, les risques.

Risques et contraintes

[ ] Un pre-mortem ou une liste de risques avec propriétaires.
[ ] Les dépendances externes cartographiées (sources, équipes, fournisseurs).
[ ] Les contraintes réglementaires et de sécurité connues.
[ ] Un budget de marge (temps, coût) explicite.

Livraison

[ ] Les environnements et la stratégie de versionnement décidés (Git en profondeur, TFVC).
[ ] Un pipeline de livraison même minimal, ou un plan pour en avoir un (CI/CD).
[ ] Une charte d'usage de l'IA si l'équipe l'utilise.
[ ] Un plan de communication minimal et un rythme de revue.

10. Checklist de revue de projet#

À utiliser tous les trimestres ou à chaque jalon. Chaque question appelle une preuve, pas une opinion.

Thème	Question	Preuve attendue
Valeur	L'objectif et les bénéfices attendus sont-ils toujours valides ?	Cas d'affaires revu, chiffres d'usage
Périmètre	Qu'avons-nous ajouté, retiré, reporté depuis le dernier jalon ?	Journal des changements
Flux	Le temps de cycle et le débit évoluent-ils ? Où sont les attentes ?	Tableau de flux, items bloqués
Qualité	Combien de défauts échappés ? La DoD est-elle tenue ?	Défauts par version, revue de DoD
Dette	La dette connue grossit-elle ou diminue-t-elle ?	Tickets de dette, part de capacité
Risques	Les risques majeurs ont-ils un propriétaire et une action datée ?	Registre à jour
Équipe	La charge, la sécurité psychologique, les compétences sont-elles saines ?	Rétrospectives, entretiens
Parties prenantes	Les attentes sont-elles alignées ? Y a-t-il des surprises ?	Retours aux reviews, enquêtes
Livraison	Les déploiements sont-ils reproductibles et réversibles ?	Journal de déploiement, essai de retour arrière
Méthode	Quelles pratiques servent encore ? Lesquelles gênent ?	Actions de rétro, retours d'équipe
Coût	Consommé vs prévu ; prévision à terminaison ?	Suivi budgétaire

Les matrices de maturité de la conduite de projet informatique et de conduite de projet data offrent une version graduée de cette revue, avec jalons vérifiables.

11. Checklist spéciale projet data#

Pour un projet de datamart, d'entrepôt ou de reporting. À ajouter aux deux checklists précédentes.

Sources et contrats

[ ] Chaque source a un propriétaire, un contrat de schéma, une fréquence et une fenêtre de disponibilité.
[ ] Un profilage de données a été fait (nuls, doublons, domaines de valeurs, volumétrie).
[ ] La détection de dérive de schéma est automatisée et bloquante.

Conception

[ ] Le grain de chaque table de faits est écrit en une phrase.
[ ] Les règles d'historisation sont décidées attribut par attribut.
[ ] Les définitions métier (client actif, chiffre d'affaires…) sont uniques, validées, versionnées.
[ ] Les clés de substitution et les règles de jointure (nullabilité) sont documentées.

Traitements

[ ] Chaque traitement est idempotent : rejoué deux fois, il donne le même résultat.
[ ] Une stratégie de reprise après interruption est écrite et testée.
[ ] Le temps de traitement est mesuré à volumétrie représentative.
[ ] Les traitements sont journalisés (début, fin, lignes, erreurs).

Qualité et recette

[ ] Des requêtes de contrôle (comptages, sommes, rapprochements) tournent à chaque chargement.
[ ] Un protocole de recette métier sur chiffres existe, avec valeurs attendues validées par écrit.
[ ] Un jeu de test non personnel existe, représentatif en forme et en volume.

Sécurité et conformité

[ ] Données personnelles identifiées, minimisées, protégées ; base juridique et durées de conservation connues.
[ ] La sécurité par rôle (RLS) est testée par profil, pas seulement paramétrée.
[ ] Les environnements de test ne contiennent pas de données de production non anonymisées.

Livraison et exploitation

[ ] Livraison par pipeline ou kit versionné, compatible avec la version précédente.
[ ] Plan de retour arrière ou de rejeu depuis la source.
[ ] Supervision de la fraîcheur, des volumes et des anomalies, avec un propriétaire d'alerte.
[ ] Dictionnaire de données et lineage régénérés à chaque version.

Adoption

[ ] Les utilisateurs clés sont formés ; un indicateur d'adoption existe.
[ ] Un canal de support et un processus de demande d'évolution sont définis.

🤖 IA

Ces checklists sont un bon matériau pour un assistant : lui fournir le dossier de projet et demander « quelles cases ne sont pas couvertes par ces documents ? » donne un premier diagnostic. Le verdict reste humain (voir IA et conduite de projet).

12. Gravité et fréquence : où concentrer ses efforts#

Appréciation d'expert sur les familles de pièges, pour une équipe de 4 à 12 personnes sur un projet BI/datamart. Ce sont des ordres de grandeur subjectifs, pas des statistiques.

Famille	Fréquence	Gravité	Détectabilité	Commentaire
A — Cadrage, valeur	4/5	5/5	2/5	Cause racine des échecs « livré mais inutile » ; détectée tard
B — Méthode, organisation	4/5	3/5	3/5	Visible en rétrospective si elle est honnête
C — Estimation, pilotage	5/5	3/5	3/5	Très fréquent, rarement fatal à lui seul
D — Équipe, communication	4/5	4/5	2/5	Les signaux faibles sont humains, pas chiffrés
E — Qualité, livraison	4/5	4/5	4/5	Les défauts finissent par se voir ; l'automatisation aide
F — Spécificités data	4/5	5/5	1/5	Erreurs silencieuses : le chiffre faux paraît juste

Lecture : les familles A et F cumulent la gravité la plus élevée avec la détectabilité la plus faible : ce sont celles qui justifient les contrôles actifs (revue de cadrage, rapprochements de chiffres). La famille C est la plus fréquente mais la moins fatale : bonne cible pour des gains rapides.

💡 Astuce d'expert

Choisissez trois pièges à surveiller par trimestre, en fonction de votre méthode (B), de votre contexte data (F) et du dernier incident. Un catalogue de 57 pièges est une encyclopédie ; trois pièges suivis sont un plan d'action.

13. Voir aussi#

Les méthodes dont les pièges sont tirés : Fondamentaux, Scrum, le cadre, Scrum en pratique, Scrum et data, Méthodes prédictives, Agiles et lean, Méthodes spécifiques data.
Choisir : Comparatif, Choisir et hybrider.
Livrer : CI/CD, CI/CD pour la data.
IA : IA et conduite de projet, synthèse transverse IA.
Outils : Azure DevOps / TFS, Métriques et reporting de projet.
Reporting : Bonnes pratiques Power BI transverses, Checklist de projet de reporting.
Mesurer sa maturité : Matrices de maturité, Auto-évaluation.
Vocabulaire : GLOSSAIRE ; bibliographie : Bibliographie et ressources.

✻ Rédigé par Claude Sonnet 5.5