Tableur, entrepôt ou lac de données : de quoi avez-vous vraiment besoin ?

« Il nous faudrait un data lake. » Je l’entends régulièrement, et je pose toujours la même question : combien de sources de données croisez-vous aujourd’hui, et sur quel volume ?

La réponse est très souvent : trois sources, quelques centaines de milliers de lignes. C’est un entrepôt de données modeste, pas un lac. Et parfois même, honnêtement, c’est encore un tableur bien tenu.

Voici comment je situe le besoin, sans vocabulaire inutile.

Le tableur : plus loin qu’on ne croit

On le méprise trop vite. Un tableur reste le bon outil quand trois conditions sont réunies : les données tiennent dans un fichier sans ramer, une seule personne les met à jour, et aucune décision engageante ne repose dessus sans vérification.

Ses avantages sont réels : tout le monde sait s’en servir, la mise en place est immédiate, et le coût est nul. Beaucoup de projets data commencent par un tableur, et c’est une bonne chose.

Ses limites arrivent toujours par le même chemin. Deux personnes modifient le même fichier, et deux versions coexistent. Une formule est recopiée de travers sur une plage, et l’erreur reste invisible pendant des mois. L’historique n’existe pas : on ne sait plus ce que le fichier disait le trimestre dernier.

Le signal de sortie : quand quelqu’un demande « c’est bien la dernière version ? », le tableur a atteint sa limite.

L’entrepôt de données : le besoin le plus fréquent

Un entrepôt, c’est une base structurée où l’on centralise les données issues de plusieurs systèmes, nettoyées et organisées pour l’analyse.

C’est ce dont a besoin l’immense majorité des entreprises avec lesquelles je travaille, et cela répond à trois besoins précis.

Croiser des sources. Le CRM, la facturation et l’outil de production ne parlent pas la même langue. L’entrepôt est l’endroit où l’on réconcilie les identifiants et où l’on décide, une fois pour toutes, ce qu’est un « client ».

Garder l’historique. Les systèmes opérationnels écrasent : quand un statut change, l’ancien disparaît. L’entrepôt conserve, ce qui permet de répondre à « où en étions-nous en mars ? » — une question qu’on ne peut plus poser une fois la donnée écrasée.

Servir plusieurs consommateurs. Tableaux de bord, exports, analyses ponctuelles puisent au même endroit, donc affichent les mêmes chiffres.

Le point important : un entrepôt n’est pas forcément un gros projet. Sur des volumes de PME, une base relationnelle bien conçue et quelques traitements planifiés suffisent. On peut le monter en quelques semaines.

Le lac de données : rarement le bon choix

Un lac stocke les données brutes, dans leur format d’origine, sans structure imposée. On range d’abord, on décide de la structure au moment de lire.

C’est pertinent dans des cas identifiables : très gros volumes, données peu structurées — textes, images, journaux d’événements, capteurs — et usages encore inconnus au moment du stockage.

Ce que cela implique et qu’on sous-estime : sans structure imposée à l’entrée, la qualité se gère à la lecture, donc par chaque utilisateur. Et il faut des compétences spécifiques pour l’exploiter. Un lac mal gouverné devient très vite un dépotoir où personne ne retrouve rien — c’est un scénario suffisamment répandu pour avoir son propre surnom dans le métier.

Ma position : si vous hésitez entre entrepôt et lac, c’est que vous avez besoin d’un entrepôt. Le lac répond à un besoin qui, quand il existe, ne laisse aucun doute.

Photo : rawpixel — licence CC0.

La grille que j’utilise

	Tableur	Entrepôt	Lac
Nombre de sources	1	2 à 20	20 et plus
Volume	< 1 million de lignes	Millions à milliards	Téraoctets
Historique conservé	Non	Oui	Oui
Plusieurs consommateurs	Non	Oui	Oui
Données non structurées	Non	Marginal	Oui
Compétences requises	Aucune	Modérées	Spécialisées
Mise en place	Immédiate	Quelques semaines	Plusieurs mois

La colonne du milieu couvre la très grande majorité des besoins réels. Ce n’est pas la plus impressionnante à annoncer en comité, et c’est presque toujours la bonne réponse.

Photo : domaine public (CC0).

Les trois signaux qu’il faut changer d’étage

Quelqu’un demande quelle est la bonne version d’un fichier. Le tableur ne suffit plus.

Deux tableaux de bord affichent des chiffres différents. Les calculs sont dupliqués : il faut une source unique, donc un entrepôt.

Une question métier reste sans réponse parce que la donnée a été écrasée. L’absence d’historisation coûte désormais quelque chose de concret. C’est le signal le plus fort, et le plus fréquemment ignoré.

Ce que coûte vraiment un entrepôt

La question du coût arrive toujours, et les réponses qu’on trouve en ligne mélangent des échelles sans rapport. Voici les postes réels, dans l’ordre où ils pèsent.

La compréhension des sources. C’est le premier poste, et de loin. Comprendre ce que contient réellement un CRM utilisé depuis huit ans — les champs détournés de leur usage, les valeurs obsolètes, les conventions officieuses — prend plus de temps que d’écrire les traitements.

Les traitements de nettoyage et de réconciliation. Faire correspondre un client entre trois systèmes qui n’ont pas le même identifiant est un travail méticuleux, et c’est là que se joue la fiabilité finale.

L’exploitation. Un entrepôt vit : les sources évoluent, les traitements cassent, les volumes grossissent. Sans quelqu’un pour surveiller, il se dégrade silencieusement — et l’on s’en aperçoit le jour où un chiffre est manifestement faux.

L’infrastructure. C’est le poste dont on parle le plus et qui pèse le moins. Sur des volumes de PME, l’hébergement d’un entrepôt coûte quelques dizaines d’euros par mois.

Autrement dit : le coût d’un entrepôt est un coût de temps humain, pas de licence. Un devis dont l’essentiel porte sur l’outil se trompe de sujet.

Photo : Elliott Chau — licence CC0.

Commencer petit, mais pas n’importe comment

Une chose que je recommande systématiquement : construire l’entrepôt sur un seul périmètre métier d’abord, complet de bout en bout.

Prenez le domaine commercial : sources identifiées, historisation en place, deux ou trois indicateurs définis et fiables, un tableau de bord utilisé. Six semaines.

Ce périmètre sert alors de modèle. Les suivants réutilisent la même structure, les mêmes conventions de nommage, les mêmes contrôles — et coûtent deux à trois fois moins cher.

L’erreur inverse — poser d’abord une infrastructure « pour tout accueillir » — produit des mois de travail invisible et un résultat que personne n’a encore utilisé.

Deux erreurs de séquencement

Choisir l’outil de visualisation avant l’entrepôt. L’outil est la partie visible, donc celle qu’on achète en premier. Branché directement sur les systèmes opérationnels, il produit des chiffres justes au départ, puis divergents dès qu’un deuxième tableau de bord apparaît — chacun refaisant ses propres calculs.

Vouloir du temps réel d’emblée. La demande est fréquente et rarement justifiée. Un rafraîchissement nocturne suffit à l’immense majorité des décisions, et il coûte une fraction du temps réel. Je pose toujours la question : quelle décision prendrez-vous à 14 h que vous ne pourriez pas prendre demain matin ? La réponse est parfois solide — et le plus souvent, elle révèle que l’exigence venait d’une habitude, pas d’un besoin.

Ce que je conseille de faire en premier

Pas d’acheter un outil. Cartographier vos sources.

Une page suffit : quels systèmes détiennent quelles données, qui les met à jour, à quelle fréquence, et lesquelles servent à décider. Cet inventaire prend deux ou trois jours et il révèle presque toujours deux choses — une source critique que personne ne sauvegarde, et deux systèmes qui détiennent la même information sans se parler.

À partir de là, le dimensionnement devient évident, et vous saurez si vous avez besoin d’un entrepôt ou simplement de mieux tenir un tableur. Les deux réponses sont respectables ; ce qui coûte cher, c’est de construire une infrastructure pour un besoin qu’on n’a pas encore.