Entrepôt de données chez un bailleur social : à quoi ça sert vraiment

« On a déjà des états dans l’ERP. » C’est la première objection, et elle est légitime. Pourquoi ajouter une base quand chaque application produit déjà ses éditions ?

Parce qu’une application métier est conçue pour répondre à une question : où en sont les choses maintenant ? Elle répond très bien. Mais elle ne sait pas répondre à deux autres questions, qui sont celles d’un pilotage.

Ce qu’aucune application métier ne sait faire

La mémoire du temps. Votre ERP sait combien de logements sont vacants aujourd’hui. Il ne sait pas combien l’étaient au 30 juin, parce qu’il a écrasé l’information en changeant de statut. Vous pouvez ressortir une extraction archivée, à condition que quelqu’un ait pensé à la faire, que le format n’ait pas changé et que les règles aient été les mêmes. Cela ne s’appelle pas un historique, cela s’appelle une collection de fichiers.

Un entrepôt conserve l’état à chaque date. La différence est qualitative : on ne compare plus des extractions, on mesure une évolution.

Les définitions partagées. Demandez à trois services ce qu’est un logement vacant. Vous obtiendrez trois réponses, toutes défendables : sans occupant, sans bail en cours, sans loyer appelé. Tant que la définition vit dans la requête de chacun, la réunion porte sur les chiffres au lieu de porter sur le sujet.

Un entrepôt force à trancher, une fois, et à écrire la règle. C’est souvent le bénéfice le plus immédiat, et il est organisationnel avant d’être technique.

Les indicateurs qui deviennent possibles

Ce ne sont pas des indicateurs exotiques. Ce sont ceux que tout le monde veut et que peu d’organismes tiennent de manière fiable, parce qu’ils supposent de croiser plusieurs sources et de conserver l’histoire :

• le délai de relocation réel, de la date de congé à la date d’entrée, et sa distribution, pas seulement sa moyenne ;
• la vacance décomposée entre technique, commerciale et de gestion, avec son évolution ;
• le délai de traitement des interventions, du signalement à la clôture, par corps d’état et par prestataire ;
• la tenue des engagements d’un marché, mesurée sur des faits et non sur des déclarations ;
• la rotation par programme, croisée avec l’ancienneté du bâti et les travaux réalisés.

Chacun de ces indicateurs demande de relier ce que plusieurs applications savent séparément. C’est exactement le rôle de l’entrepôt, et c’est pourquoi il vient après l’interopérabilité, jamais avant.

Le sous-produit qu’on n’attendait pas : les API

Dans la vie d’une DSI, chaque nouveau projet arrive avec la même demande : « il nous faudrait un accès aux données ». Application mobile, portail prestataire, outil partenaire, expérimentation IA. Et chaque fois, la même discussion : ouvrir un accès à l’ERP, avec quels droits, avec quel risque.

L’entrepôt tranche ce débat. Il est déjà une copie propre, historisée, aux définitions explicites. Exposer une API dessus est naturel : on choisit ce qu’on publie, on le documente, on le versionne, on le limite. Et surtout, l’ERP reste fermé.

Ces mêmes API servent ensuite les agents IA, pour une raison simple : un assistant n’est utile que s’il interroge des données réelles avec des droits maîtrisés. Un entrepôt bien construit est la meilleure porte d’entrée qu’on puisse leur donner.

Ce qu’il ne faut pas en attendre

Ce n’est pas un pivot opérationnel. Un entrepôt sert à analyser, pas à faire tourner la production. Si vous comptez faire transiter vos flux métier par lui, vous construisez autre chose, et probablement quelque chose de fragile.

Il ne corrige pas vos données. Un entrepôt rend visibles les incohérences qui existaient déjà et que personne ne regardait. C’est un service, mais les premières semaines sont désagréables : on découvre les doublons, les champs détournés, les statuts qui ne correspondent à rien. Il vaut mieux le savoir avant de commencer.

Il ne remplace pas la décision. Un tableau de bord qui n’a pas de destinataire nommé et de décision associée ne sera pas regardé au bout de trois mois. Commencez par l’indicateur qui manque à quelqu’un de précis, pas par le catalogue complet.

Par quoi commencer

Par un seul indicateur, celui que votre direction réclame et que personne ne sait produire sans deux jours de travail manuel. Construisez-le proprement : la source, la définition écrite, l’historique, la possibilité de descendre jusqu’aux cas concernés.

Un indicateur juste et opposable change davantage de choses qu’un schéma directeur de la donnée.

---

Vous voulez en parler pour votre organisme ? Écrivez-nous à contact@oxli.io ou demandez une démonstration.