Data mesh : la découpe en domaines qui calque l'organigramme

Dans un programme data mesh, tout part d'une question apparemment simple : comment découper le système d'information en data products ? Cette décision est antérieure à tout choix technique. Elle précède Snowflake, Databricks ou Iceberg. Et elle est, de loin, la plus difficile à corriger une fois prise.

La raison est structurelle. Un data product n'est pas un simple dataset : c'est une unité dotée d'un propriétaire, d'un contrat d'interface, de SLO de qualité et d'une équipe responsable. Quand vous tracez la frontière entre deux domaines, vous tracez en réalité une frontière organisationnelle, contractuelle et technique simultanément. La déplacer six mois plus tard suppose de redécouper les équipes, de réécrire les contrats de données et de reconstruire des pipelines déjà en production.

C'est pourquoi un mauvais découpage initial ne se rattrape pas par un correctif : il se paie par un re-build. Et c'est précisément cette caractéristique qui transforme une erreur de conseil en préjudice à plusieurs centaines de milliers d'euros, dont le client cherchera à vous tenir responsable.

La tentation la plus naturelle, et la plus dangereuse, consiste à découper les domaines en recopiant l'organigramme du client. Une direction marketing, un domaine marketing. Une direction supply, un domaine supply. C'est rapide, c'est consensuel en atelier, et c'est faux.

La loi de Conway énonce qu'une organisation produit des systèmes qui reflètent sa structure de communication. Appliquée au data mesh, elle se retourne contre le programme : si vous découpez les data products selon l'organigramme actuel, vous gravez dans la plateforme data les silos et les frictions politiques que le data mesh était censé dissoudre. Les domaines se recouvrent, des data products dupliquent la même donnée client, et la gouvernance fédérée devient ingérable.

Un découpage data mesh ne doit pas refléter qui dirige quoi aujourd'hui, mais quels sont les domaines métier stables qui produisent et consomment de la donnée. Ces deux cartes coïncident rarement.

Le problème, c'est que l'arbitrage entre « découpe par organigramme » (politiquement facile) et « découpe par domaine métier » (techniquement saine) est souvent tranché par le client contre votre avis, pour des raisons internes. Si vous n'avez pas tracé votre recommandation, vous porterez la responsabilité d'un choix que vous n'avez pas fait.

L'enchaînement est presque toujours le même. Phase 1 : la découpe est validée en comité, dans l'enthousiasme du lancement. Phase 2 : les premiers data products sortent, on découvre que deux domaines se disputent la donnée « client », et que personne n'est clairement propriétaire. Phase 3 : la qualité se dégrade, les délais glissent, le sponsor s'inquiète. Phase 4 : un audit interne ou un cabinet tiers est mandaté, et conclut que l'architecture de domaines était mal posée dès l'origine.

À ce stade, le client cherche un responsable. Votre note de cadrage, vos slides d'atelier et vos comptes rendus deviennent des pièces. Si elles montrent que vous avez recommandé la découpe défaillante, la faute de conseil est caractérisée. Le préjudice invoqué est immatériel : retard du programme, coût de reconstruction, perte de valeur attendue. Les montants en jeu sur un programme data mesh de grand compte se comptent en millions.

C'est exactement le scénario que couvre votre assurance RC Pro : elle indemnise les conséquences financières d'une faute, d'une erreur ou d'une omission de conseil, et prend en charge vos frais de défense, y compris lorsque la réclamation est partiellement contestable.

La meilleure défense d'un consultant data mesh ne se joue pas au moment du litige, mais au moment de la découpe. Trois réflexes documentaires font la différence.

• Le registre des hypothèses. Chaque frontière de domaine repose sur des hypothèses (volumétrie, stabilité métier, propriété fonctionnelle). Écrivez-les. Une hypothèse fausse dont le client connaissait l'existence n'est pas une faute cachée.
• Le journal des arbitrages. Quand le client impose une découpe par organigramme contre votre avis, formalisez-le par écrit : votre recommandation, la décision retenue, les risques signalés. Un mail récapitulatif suffit.
• Les alertes datées. Dès que vous observez un recouvrement de domaines ou un conflit de propriété, alertez par écrit. Une alerte ignorée déplace la responsabilité vers le décideur.

Ces traces ne vous dispensent pas d'une couverture : elles la rendent efficace. Un assureur défend bien mieux un dossier où le consultant a alerté et documenté qu'un dossier où l'historique des décisions a disparu dans des échanges oraux.

Beaucoup de consultants data mesh interviennent uniquement sur la phase amont : ils dessinent la cible, recommandent la découpe, puis passent la main à une ESN ou aux équipes internes pour la réalisation. Ils se croient protégés : « je n'ai rien construit ».

C'est une illusion. La faute de conseil ne suppose pas que vous ayez codé quoi que ce soit. Si la découpe que vous avez recommandée est jugée intrinsèquement inadaptée au contexte, votre responsabilité contractuelle est engagée pour le préjudice qui en découle, même si l'échec s'est matérialisé entre les mains d'un tiers. Le maître d'ouvrage vous reprochera la cause racine, pas l'exécution.

À l'inverse, une mission de cadrage bien bornée, avec un livrable décrivant explicitement le périmètre de votre conseil et les conditions de réussite hors de votre contrôle, limite votre exposition. La frontière entre « ce que je recommande » et « ce que je ne garantis pas » doit figurer noir sur blanc dans le livrable.

Pour mesurer concrètement l'enjeu, déroulons un cas réaliste. Un grand compte lance un programme data mesh estimé à plusieurs millions d'euros sur dix-huit mois. Le consultant recommande, sous la pression du sponsor, une découpe par directions : un domaine par grande entité de l'organisation. Six mois plus tard, trois directions se disputent la propriété de la donnée « client unique », chacune ayant créé son propre data product. La donnée diverge, les chiffres ne se réconcilient plus en comité de direction.

Un cabinet tiers est mandaté. Son diagnostic est sans appel : la découpe par organigramme a ressuscité les silos, il faut redécouper autour de quelques domaines métier transverses et reconstruire les data products concernés. Le coût du re-build est chiffré : plusieurs centaines de milliers d'euros de prestations, auxquels s'ajoutent six mois de retard et la valeur métier non délivrée sur la période.

Dans ce dossier, l'existence d'un mail où le consultant recommandait la découpe par domaines métier et alertait sur les risques de la découpe par organigramme change tout : elle déplace la responsabilité vers le sponsor décideur. Sans ce mail, le consultant porte seul la cause racine.

Un consultant data mesh n'a pas le même profil de risque qu'un développeur ou qu'un data engineer d'exécution. Son exposition est concentrée sur le conseil de haut niveau : architecture, découpe, gouvernance. Le sinistre type n'est pas un bug, c'est un programme qui dévie de plusieurs millions.

Votre couverture doit donc viser juste : des plafonds dimensionnés à la taille des programmes que vous accompagnez (un grand compte n'a pas le profil d'une PME), une garantie explicite des dommages immatériels et du préjudice financier, et une couverture des missions menées en France comme dans l'Union européenne si vous intervenez sur des organisations multi-pays.

Pour comprendre dans le détail ce que recouvre cette garantie et comment elle s'articule avec votre profil, consultez notre page dédiée à l'assurance RC Pro, ou notre fiche métier consultant data mesh pour un tarif adapté.