Pourquoi les projets data se bloquent entre métiers, Data et IT

Un projet peut être très actif et ne plus avancer

La démonstration du tableau de bord a convaincu. Pourtant, trois mois plus tard, les utilisateurs travaillent encore dans leurs fichiers. Le métier attend un indicateur fiable, la Data attend une définition stabilisée et l’IT attend la validation du dispositif d’exploitation. Chacun peut justifier son attente. Le planning, lui, continue de glisser.

Qualifier cette situation de problème de communication reste insuffisant. Il faut identifier ce qui manque pour franchir la prochaine étape : une décision, une preuve, une compétence ou une capacité disponible. Une réunion supplémentaire ne produit pas automatiquement l’un de ces éléments.

La méthode proposée ici consiste à rendre les interfaces de travail explicites : qui attend quoi, de qui, pour décider quoi ? Elle s’applique aussi bien à un reporting financier qu’à un référentiel industriel ou à un outil de planification. Elle ne résout pas une pénurie de ressources, mais permet de la distinguer d’un désaccord encore non arbitré.

Nommer le blocage avant de chercher le responsable

Prenez les trois derniers retards et décrivez des faits observables. « Le métier ne s’implique pas » est un jugement. « Personne n’est habilité à accepter l’exclusion des commandes annulées » désigne une décision manquante. « L’IT bloque » devient « le transfert attend une validation de sécurité dont le dossier est incomplet ».

Utilisez cette grille pour qualifier chaque obstacle. Plusieurs causes peuvent coexister : un manque de capacité technique n’efface pas une définition ambiguë. Traitez-les séparément, avec leurs propres actions de résolution.

Écrire un contrat de décision d’une page

Avant de détailler toutes les fonctionnalités, formalisez le changement recherché. Pour un suivi des retards fournisseurs, il peut s’agir de choisir chaque semaine les commandes à relancer et les réapprovisionnements à anticiper. « Créer un dashboard achats » ne précise ni l’utilisateur, ni l’action, ni le résultat attendu.

Ce contrat n’est pas un cahier des charges figé. C’est un accord de départ, révisable lorsque de nouvelles informations apparaissent. Il sert à juger si une demande supplémentaire renforce l’objectif ou élargit simplement le projet.

• Décision : quelle action l’utilisateur pourra-t-il mieux choisir, et à quelle fréquence ?
• Périmètre : quelles activités sont couvertes, et lesquelles sont explicitement exclues ?
• Preuve : comment vérifier que l’information est suffisamment fiable pour cet usage ?
• Arbitrage : qui tranche un conflit de priorité, de définition ou de niveau de service ?
• Capacité : quels temps métier, Data et IT sont réellement réservés ?
• Après lancement : qui maintient les règles, traite les incidents et finance l’exploitation ?

Distribuer les décisions, pas seulement les tâches

Une matrice de responsabilités devient utile lorsqu’elle indique des droits d’arbitrage. Le responsable métier précise l’usage et accepte les compromis fonctionnels. Les responsables Data et IT proposent une solution réalisable et précisent leurs contraintes de qualité, d’intégration et d’exploitation. Leur partage exact dépend de votre organisation ; il doit être explicité plutôt que présumé.

Le porteur de direction tranche les conflits qui dépassent ces mandats, notamment entre budgets ou priorités de plusieurs directions. Il n’a pas à choisir chaque règle de calcul. À l’inverse, un chef de projet chargé de coordonner ne peut pas remplacer un décideur absent s’il ne dispose pas de son autorité.

Le Scrum Guide distingue notamment la responsabilité du Product Owner sur la valeur et l’ordonnancement du travail. Le Service Manual britannique souligne le besoin d’équipes pluridisciplinaires, de gestion des dépendances et de compétences d’exploitation. Ces repères ne prescrivent pas votre organigramme : ils invitent à vérifier que les responsabilités indispensables sont effectivement couvertes.

Piloter les attentes entre équipes

Un planning qui présente uniquement les tâches de l’équipe Data masque les engagements nécessaires chez les autres. Ajoutez les dépendances : accès à une source, évolution d’une interface, validation d’un référentiel, recette métier, disponibilité de l’exploitation. Pour chacune, notez un fournisseur, un consommateur, un résultat attendu et une date convenue.

Distinguez une estimation technique d’un engagement de capacité. Une intervention de deux jours peut commencer dans six semaines. Ce décalage ne disparaît pas parce que la charge paraît faible. Si plusieurs projets sollicitent la même personne, l’arbitrage doit porter sur leur ordre de passage.

Limitez ensuite les chantiers ouverts à ce que les équipes peuvent terminer. Commencer un nouveau cas d’usage pendant qu’un précédent attend sa recette peut donner une impression de progression tout en accumulant des livraisons inutilisées. La revue hebdomadaire doit rendre visibles les éléments bloqués, leur ancienneté et la prochaine décision attendue.

S’accorder sur ce que signifie « utilisable »

Un calcul exact sur un périmètre incomplet peut conduire à une mauvaise décision. La recette doit donc tester le sens des données, les cas limites et leurs conditions d’utilisation, en plus du fonctionnement technique. Le Scrum Guide formalise une définition commune de l’achèvement à partir des exigences de qualité du produit. Nous proposons d’en traduire le principe en preuves adaptées à chaque usage data.

Pour un reporting de stock, vérifiez par exemple les transferts en cours, les unités de mesure, les corrections tardives et la date de fraîcheur affichée. Définissez le comportement en cas d’échec d’alimentation : masquer un résultat, signaler son ancienneté ou suspendre une alerte. Le choix dépend des conséquences possibles.

La mise en service inclut aussi des utilisateurs disponibles pour tester, un responsable des incidents et une procédure de retour au fonctionnement précédent. Ces conditions se préparent pendant le développement ; les découvrir à la fin transforme la dernière étape en nouveau projet.

Exemple fictif : débloquer un suivi des retards fournisseurs

Considérons une entreprise industrielle fictive. Les achats souhaitent classer les fournisseurs en retard. La production veut anticiper les ruptures. La première version rapproche la commande et la réception physique, mais les acheteurs contestent les résultats : les dates promises ont été renégociées, parfois sans historique conservé.

Le désaccord porte sur deux usages distincts. Mesurer la tenue de l’engagement initial exige un historique que la source ne permet pas encore de reconstruire. Préparer les relances de la semaine peut utiliser la dernière date promise, à condition d’en expliciter la limite.

L’équipe propose donc deux trajectoires. Elle livre d’abord une liste opérationnelle de commandes ouvertes, sur un site pilote, selon une règle validée par achats et production. Elle documente la couverture et les commandes exclues. En parallèle, elle planifie avec l’IT la conservation des changements de dates pour rendre possible une future analyse de performance fournisseur.

Dans cet exemple, l’arbitrage consiste à conserver le premier usage et à différer le second. Le projet ne prétend plus mesurer ce que les données ne permettent pas d’établir. Le responsable des achats accepte le périmètre ; l’équipe Data prépare les contrôles ; l’IT confirme l’exploitation ; les utilisateurs évaluent l’utilité réelle lors des relances. Aucun gain chiffré n’est présumé.

Accélérer implique parfois de réduire ou d’arrêter

Face à une contrainte, rendez les options comparables : réduire le périmètre, allonger le délai, déplacer une capacité ou abandonner l’usage. Un traitement manuel temporaire peut aider à tester une règle, s’il est autorisé, traçable et assorti d’une date de réexamen. Il devient fragile lorsque personne ne sait qui le maintient.

Certaines limites ne se négocient pas dans le seul comité projet : une obligation applicable, une exigence de sécurité ou un risque opérationnel majeur nécessite l’avis des responsables habilités. Le portage de direction sert à obtenir un arbitrage éclairé, pas à contourner ces responsabilités.

Enfin, si aucun utilisateur ne peut expliquer quelle décision sera améliorée, suspendre le développement peut être raisonnable. Une reprise ciblée du cadrage coûte du temps ; poursuivre une solution sans usage identifié engage aussi des coûts de maintenance futurs.

Les premiers pas : une revue de déblocage en dix jours

Choisissez un projet précis. Dans les premiers jours, reconstituez ses dernières attentes et remplissez la grille avec les trois équipes. Rédigez ensuite le contrat de décision, puis réunissez uniquement les personnes nécessaires aux arbitrages ouverts. L’objectif de cette séquence indicative est de convenir d’une prochaine livraison crédible, pas de promettre un redressement complet en dix jours.

Évitez trois raccourcis : ajouter un comité sans mandat, nommer un responsable sans disponibilité et déclarer une dépendance résolue sur la base d’une simple intention. Exigez une décision datée, une capacité confirmée ou une preuve observable.

Suivez enfin le temps passé en attente, les décisions échues et la réouverture des sujets déjà arbitrés. Reliez ces mesures à l’usage : l’information sert-elle désormais à agir ? Ce suivi aide à ajuster le fonctionnement entre métiers, Data et IT sans transformer le pilotage en exercice documentaire.

Questions fréquentes