Données sans propriétaire en PME : le risque SI que personne ne voit venir

La donnée partagée qui devient la donnée de personne

Commencez par une scène concrète. Lors d'une réunion commerciale, le responsable des ventes cite un chiffre de pipeline. La directrice financière en cite un différent pour le même mois. Le responsable des opérations en a un troisième dans son tableau de bord. Personne ne ment, personne ne travaille à partir de données erronées. Chacun travaille depuis sa propre source, avec ses propres critères de filtrage, ses propres colonnes exclues.

Ce scénario n'est pas rare dans les PME de cinquante à deux cents salariés. C'est même la norme dès lors que l'entreprise a grandi plus vite que son système d'information. Plusieurs outils coexistent, les équipes extraient, croisent, retraitent dans des fichiers locaux, et la donnée finale que chacun utilise n'est plus la même que celle de son voisin. Le problème n'est pas la qualité des données. C'est l'absence de source de vérité définie.

Derrière ce phénomène se cache une question que personne n'a explicitement posée : qui est responsable de cette donnée ? Pas au sens de qui la saisit, mais au sens de qui décide quelle version fait foi, qui prévient les autres quand elle change, et qui répond quand une incohérence est détectée. Dans la grande majorité des PME, cette question n'a pas de réponse formalisée. Et c'est là que commence le problème.

Pour comprendre pourquoi un SI fragmenté produit ces symptômes à grande échelle : six signes que votre SI freine votre croissance.

Pourquoi les règles métier implicites amplifient le risque

Le problème de propriétaire de données ne se limite pas à la question de la source. Il s'étend aux règles qui régissent comment la donnée doit être interprétée, transformée ou utilisée. Ces règles sont rarement écrites. Elles sont dans la tête des personnes qui travaillent avec la donnée depuis le plus longtemps.

Exemple typique dans un service commercial : une remise de quinze pour cent s'applique à tous les clients avec plus de trois ans d'ancienneté, sauf pour les clients du secteur B ayant un contrat-cadre, sauf pour ceux qui ont renégocié leur tarif avant 2023. La personne qui le sait, c'est Sophie, responsable ADV depuis huit ans. Quand Sophie prend ses congés, les nouvelles recrues font des erreurs de prix. Quand Sophie part à la retraite, la règle disparaît avec elle. Quand on commence à développer un outil de gestion des remises, personne ne sait exactement quoi coder.

« Les règles métier, comme dans beaucoup d'entreprises, existaient déjà dans la tête des gens. Chacun était bien responsable de son périmètre. Maintenant, le tout c'était de réussir à comprendre là où ça coinçait, là où ça bloquait, là où il y avait de la perte d'information. »

L'absence de propriétaire de données et l'absence de règles formalisées se renforcent mutuellement. Sans propriétaire défini, personne n'est habilité à formaliser les règles. Sans règles formalisées, la donnée ne peut pas être gouvernée sérieusement. Les deux problèmes doivent être traités ensemble, avant tout développement.

Ce qu'un propriétaire de données fait concrètement

Le propriétaire de données n'est pas un data engineer. Ce n'est pas non plus un architecte SI. C'est une personne capable de répondre à trois questions sur une entité clé de votre SI.

Première question : qui crée cette donnée, et selon quel critère ?Pour une fiche client, est-ce que c'est le commercial qui l'ouvre dès le premier contact, ou l'ADV qui la crée à la signature ? La réponse conditionne qui voit quoi, à quel moment, avec quel niveau de complétude.

Deuxième question : qui a le droit de la modifier, et dans quelles circonstances ? Si plusieurs équipes peuvent modifier les informations de facturation d'un client, la donnée finira par refléter la dernière modification, pas la bonne. Définir les droits d'édition, c'est définir qui est responsable de l'exactitude.

Troisième question : quelle version fait foi quand il y a un conflit ?Si la fiche CRM diffère de l'ERP, laquelle est correcte ? La réponse ne peut pas être « ça dépend ». Elle doit être systématique, connue de tous, et applicée par l'outil. Le propriétaire de données est la personne qui tranche.

Ces trois questions permettent de construire une matrice de responsabilités par entité. Ce travail prend quelques jours dans une PME de taille standard. Son impact sur la qualité des développements ultérieurs est considérable. Pour approfondir la dimension modèle de données : les trois décisions sur votre modèle de données que l'IA ne peut pas prendre à votre place.

BKW Énergie France : quand la documentation sauve un audit de groupe

En novembre 2025, BKW Énergie France (filiale française d'un groupe suisse) démarrait avec Leando après une première tentative avec des freelances qui avait abouti à des projets partant dans toutes les directions. Le constat à l'arrivée : les règles métier du secteur de l'énergie, denses et techniques (soutirage, injection, tarification TURPE, règles Enedis), existaient dans la tête des équipes, pas dans un modèle partagé. La ressaisie généralisait les erreurs. La dépendance à certains collaborateurs clés fragilisait la continuité opérationnelle.

Le travail mené sur les objets métier, le modèle de données et les règles implicites a produit une documentation structurée, mise à jour en parallèle des développements. Quelques mois plus tard, lors de l'audit annuel mandaté par le groupe suisse, le cabinet d'audit a pu s'appuyer sur cette documentation. Le DSI Olivier a rapporté à Donatien que le contraste avec l'audit 2024, décevant, était « jour et nuit ».

Ce résultat illustre une chose importante : la gouvernance des données n'est pas seulement un enjeu de projet SI, c'est un actif stratégique visible de l'extérieur. Un cabinet d'audit, un partenaire financier, un acquéreur potentiel : tous évaluent votre SI non pas sur ce qu'il fait, mais sur votre capacité à expliquer comment il fonctionne et qui en est responsable. Pour comprendre comment la documentation devient cet actif : pourquoi la documentation first est rare et ce qu'elle vaut vraiment.

Par où commencer quand votre SI n'a pas de propriétaires de données

Trois actions concrètes permettent de démarrer sans attendre de refondre tout le SI.

Identifier les cinq entités les plus critiques de votre SI. En général : client, contrat ou commande, produit ou prestation, collaborateur, facture. Ce sont les données dont la qualité détermine la qualité de tout le reste. Pour chacune, posez les trois questions du paragraphe précédent en entretien avec les responsables de chaque service qui interagit avec elle.

Formaliser une règle de versionning simple. Pour chaque entité, définir une source primaire (le CRM, l'ERP, le fichier partagé, peu importe) et une règle de mise à jour. Pas besoin d'un système complexe : un document partagé avec un tableau « entité / source primaire / responsable / processus de mise à jour » suffit pour démarrer.

Traiter les conflits de données existants avant de coder. Si vous identifiez des divergences entre vos outils sur une entité clé, résolvez-les manuellement avant de démarrer un développement. Coder par-dessus des données conflictuelles produit des systèmes qui héritent des incohérences. La migration de données est toujours plus difficile après la mise en production qu'avant.

Si un prestataire vous propose de démarrer le développement avant d'avoir clarifié ces points, c'est un signal d'alerte. Il n'anticipe pas les conflits : il les découvrira en production, à vos frais.