Quels usages une plateforme data doit réellement supporter ?

La plupart des plateformes data sont conçues à l'envers. On choisit d'abord une pile technologique, on la déploie, puis on cherche à quoi elle va servir. Le résultat est prévisible : un socle capable de tout faire en théorie, mais mal ajusté à ce que les métiers demandent vraiment. On a construit une capacité, pas une réponse.

Le problème n'est pas la technologie, qui est abondante et performante. Le problème est l'absence de question préalable : à quoi cette plateforme doit-elle servir, concrètement, et pour qui ? Sans cette question, on dimensionne au jugé, on ajoute des briques par précaution, et on finit avec une plateforme surdimensionnée sur certains usages et défaillante sur d'autres.

Une plateforme data n'a pas de valeur en soi. Elle en a par les usages qu'elle rend possibles : décider sur des chiffres fiables, explorer une question, donner aux métiers un accès autonome à la donnée, alimenter un modèle prédictif, faire tourner une application. Ces usages n'ont ni les mêmes exigences ni la même criticité. Les confondre, c'est se condamner à mal servir la plupart d'entre eux.

Savoir quels usages une plateforme doit réellement supporter est donc le premier acte de conception, avant tout choix d'outil. Cela suppose de recenser les usages qui existent vraiment, de distinguer ceux qui comptent de ceux qui encombrent, et de comprendre ce que chacun exige concrètement du socle.

Partir des usages, pas des capacités techniques d'une plateforme data

La tentation permanente consiste à raisonner en capacités : quelle technologie adopter, quel entrepôt, quel outil de transformation. Ce raisonnement met la charrue avant les bœufs. Une plateforme data se dimensionne sur ce qu'elle doit produire pour les métiers, pas sur ce que la technologie sait faire.

Pourquoi une plateforme se dimensionne sur ses usages, jamais sur la technologie disponible

Une capacité technique n'a de valeur que si un usage la justifie. Un entrepôt capable de traiter le temps réel ne sert à rien si aucun usage n'a besoin de fraîcheur immédiate. Une brique de traitement massif est inutile si les volumes réels restent modestes. Choisir une capacité sans usage qui l'exige, c'est payer pour une puissance qui dort.

Le raisonnement par les usages inverse la logique. On part de ce que les métiers font ou veulent faire avec la donnée, puis on en déduit les capacités nécessaires. Cette démarche produit une plateforme ajustée, où chaque brique répond à un besoin identifié, plutôt qu'un empilement de fonctionnalités dont la moitié ne sert jamais.

Cette discipline est aussi ce qui protège la plateforme dans le temps. Une plateforme conçue autour d'usages réels évolue avec eux, de façon lisible. Une plateforme conçue autour de capacités techniques dérive au gré des modes technologiques, sans jamais coller aux besoins.

La question à poser avant tout choix : qui consomme la donnée, et pour quoi faire ?

Avant de choisir quoi que ce soit, une seule question compte : qui va utiliser cette donnée, et dans quel but ? La réponse détermine tout le reste. Un contrôleur de gestion qui consulte un tableau de bord mensuel n'a pas les mêmes besoins qu'un data scientist qui entraîne un modèle, ni qu'une application qui interroge la donnée en continu.

Répondre à cette question suppose d'aller voir les métiers, pas de le deviner depuis l'IT. Les usages réels se découvrent en observant comment les équipes travaillent avec la donnée aujourd'hui, quelles décisions elles prennent, où elles perdent du temps. Une plateforme utile naît d'une conversation avec ses futurs utilisateurs, pas d'un catalogue de fonctionnalités.

Cette question doit être posée usage par usage, sans les mélanger. Chaque usage a son consommateur, son objectif, sa fréquence, sa criticité. Les traiter en bloc conduit à une plateforme moyenne, qui sert mal chacun d'eux. Les traiter séparément permet d'ajuster le socle à la réalité de chaque besoin.

Le piège de la plateforme qui supporte tout « au cas où »

Face à l'incertitude, le réflexe est de tout prévoir. On dimensionne pour le temps réel au cas où un usage l'exigerait un jour, on prévoit des volumes massifs au cas où les données exploseraient, on ajoute des briques pour des usages hypothétiques. Cette prudence apparente est en réalité une source majeure de complexité et de coût.

Une plateforme qui supporte tout « au cas où » supporte mal l'essentiel. Les ressources consacrées à des usages hypothétiques manquent aux usages réels. La complexité ajoutée pour parer à toute éventualité rend la plateforme plus difficile à exploiter et à gouverner. C'est souvent ainsi que la facture d'une plateforme explose sans qu'on comprenne pourquoi : on paie pour des capacités que personne n'utilise.Les grands types d'usages qu'une plateforme data doit couvrir

Avant de trancher lesquels servir en priorité, il faut connaître la palette des usages qu'une plateforme peut avoir à supporter. Ils se regroupent en quelques grandes familles, chacune avec sa logique propre :

• Le reporting et la BI : la donnée pour décider, avec une exigence de fiabilité avant tout.
• L'analyse ad hoc : la donnée pour comprendre, avec un besoin de souplesse et d'accès à la donnée détaillée.
• Le self-service : la donnée mise entre les mains des métiers, avec une forte exigence de gouvernance.
• L'IA et le prédictif : la donnée pour anticiper, très exigeants en qualité et en historique.
• L'alimentation d'applications : la donnée pour agir, exigeante en fraîcheur et en disponibilité.

Les nommer clairement est le préalable à toute décision de dimensionnement.

Le reporting et la BI : la donnée pour décider

Le reporting et la business intelligence sont l'usage le plus répandu et souvent le plus critique. Il s'agit de produire des indicateurs fiables, consolidés, consultés régulièrement pour piloter l'activité. Un tableau de bord commercial, un suivi budgétaire, un reporting réglementaire relèvent de cette famille.

Cet usage exige avant tout de la fiabilité et de la cohérence. Un chiffre de reporting doit être juste, traçable et identique quel que soit l'endroit où on le consulte. La fraîcheur, en revanche, est rarement critique : un reporting mensuel ou hebdomadaire suffit à la plupart des décisions de pilotage. La BI ne demande pas de la vitesse, elle demande de la confiance.

La bonne posture n'est pas de tout prévoir, mais de couvrir les usages réels et de garder la capacité d'en ajouter. Une plateforme bien conçue n'anticipe pas tous les usages possibles : elle sert les usages présents et reste ouverte à l'évolution. Prévoir l'inconnu coûte cher ; rester capable d'évoluer coûte peu.

L'exploration et l'analyse ad hoc : la donnée pour comprendre

À côté du reporting régulier, il existe un usage plus ponctuel : l'analyse ad hoc, qui consiste à interroger la donnée pour répondre à une question précise, souvent inédite. Comprendre pourquoi les ventes ont chuté sur un segment, identifier un comportement client, tester une hypothèse : ces analyses ne suivent pas un format figé.

Cet usage exige de la souplesse et un accès large à la donnée brute ou préparée. L'analyste a besoin de pouvoir croiser des sources, creuser, itérer, sans être limité à des indicateurs prédéfinis. La contrepartie est un besoin de compétences : l'analyse ad hoc suppose des profils capables de manipuler la donnée, ce qui la distingue du reporting consultable par tous.

Le self-service : la donnée mise entre les mains des métiers

Le self-service vise à rendre les métiers autonomes : leur permettre de construire leurs propres analyses et tableaux de bord sans dépendre systématiquement de l'IT ou de la data. C'est un usage à fort levier, car il libère les équipes centrales et rapproche la donnée de ceux qui la comprennent le mieux.

Cet usage exige un socle particulièrement soigné. Pour que le self-service fonctionne, la donnée mise à disposition doit être fiable, documentée et cadrée, faute de quoi chacun produit ses propres chiffres divergents. Le self-service ne réussit pas par la seule mise à disposition d'un outil : il réussit quand la donnée sous-jacente est gouvernée et compréhensible. Ouvrir le self-service sur une donnée mal maîtrisée, c'est industrialiser la confusion.

Les cas d'usage IA et prédictifs : la donnée pour anticiper

L'analyse prédictive et les cas d'usage d'intelligence artificielle forment une famille à part. Prévoir une demande, détecter une anomalie, scorer un risque : ces usages ne consultent pas la donnée, ils l'apprennent. Ils reposent sur des modèles entraînés, qui exigent des données en quantité, en qualité et sur une profondeur d'historique suffisante.

Cet usage est le plus exigeant en matière de qualité de la donnée, car la mauvaise qualité des données est le premier risque des projets IA. Il peut aussi imposer des besoins spécifiques de fraîcheur ou de volume, mais pas systématiquement. La question de savoir s'il faut une architecture spécifique pour l'IA se pose précisément ici : dans la majorité des cas, un socle sain suffit, seuls certains usages appellent des briques dédiées.

L'alimentation d'applications et de flux opérationnels : la donnée pour agir

Enfin, une plateforme peut avoir à alimenter des applications ou des processus opérationnels : envoyer une donnée à un CRM, déclencher une action, servir une recommandation en continu. Ici, la donnée ne sert pas à décider ou à comprendre, elle sert à faire fonctionner un système en temps réel ou quasi réel.

Cet usage est le plus exigeant en matière de fraîcheur et de disponibilité. Une donnée qui alimente une application doit arriver vite, de façon fiable et sans interruption, car une défaillance a un effet direct sur le service rendu. C'est souvent le seul usage qui justifie réellement des capacités de traitement en continu, là où les autres se contentent de traitements périodiques.

Distinguer les usages réels des usages supposés d'une plateforme data

Connaître les familles d'usages ne suffit pas : encore faut-il savoir lesquels concernent vraiment l'organisation. La plupart des plateformes surdimensionnées le sont parce qu'elles ont été pensées pour des usages supposés, imaginés, plutôt que pour des usages constatés. Faire ce tri est décisif.

Recenser les usages qui existent vraiment plutôt que ceux qu'on imagine

Le point de départ d'un bon dimensionnement est un recensement honnête des usages réels. Non pas ce que l'on pense que les métiers voudront, mais ce qu'ils font aujourd'hui et ce qu'ils demandent explicitement. Ce recensement révèle presque toujours un écart entre les usages fantasmés et les usages effectifs.

L'exercice consiste à lister, usage par usage, qui l'utilise, à quelle fréquence, pour quelle décision. Un usage sans utilisateur identifié n'est pas un usage, c'est une hypothèse. Une plateforme se dimensionne sur des usages nommés, pas sur des intentions vagues. Cette photographie du réel est le socle de toutes les décisions suivantes.

Ce recensement gagne à être rattaché à une stratégie data explicite, qui indique vers quels usages l'organisation veut aller. Sans cette direction, on recense l'existant sans savoir lequel privilégier. Avec elle, on distingue les usages qui servent les objectifs de ceux qui ne sont que des habitudes.

Séparer les usages critiques des usages accessoires

Tous les usages recensés n'ont pas la même importance. Certains sont critiques : leur défaillance a un impact direct sur l'activité, les décisions ou le service. D'autres sont accessoires : utiles, mais dont l'indisponibilité passagère ne prête pas à conséquence. Cette distinction commande le niveau d'exigence de la plateforme pour chacun.

Un usage critique justifie de la robustesse, de la disponibilité, une gouvernance stricte. Un usage accessoire peut se contenter d'un traitement plus léger. Traiter tous les usages avec le même niveau d'exigence est un gaspillage dans un sens et un risque dans l'autre : on surinvestit sur l'accessoire et on sous-investit sur le critique. Hiérarchiser les usages, c'est concentrer les moyens là où la défaillance coûte le plus cher.

Reconnaître les usages qui ne justifient pas une plateforme dédiée

Certains besoins ne relèvent tout simplement pas d'une plateforme data et peuvent être servis par des moyens plus simples, sans mobiliser le socle central :

• Le besoin rare : un tableau consulté par quelques personnes une fois par trimestre.
• Le besoin ponctuel : une extraction unique, sans récurrence à industrialiser.
• Le besoin isolé et stable : une donnée qui n'évolue pas et ne croise rien d'autre.

Vouloir tout faire passer par la plateforme est une erreur fréquente, qui l'alourdit sans bénéfice.

Reconnaître ces cas évite d'alourdir la plateforme avec des usages qui ne le méritent pas. La question à se poser est simple : cet usage gagne-t-il vraiment à être industrialisé, ou un outil bureautique bien tenu suffit-il ? Répondre honnêtement à cette question allège la plateforme des usages marginaux et lui permet de se concentrer sur ceux qui comptent.

Ce que chaque usage exige réellement d'une plateforme data

Une fois les usages réels identifiés et hiérarchisés, il reste à comprendre ce que chacun exige concrètement du socle. C'est cette traduction des usages en exigences techniques qui permet de dimensionner juste. Quatre dimensions suffisent à caractériser les besoins de la plupart des usages :

• La fraîcheur : temps réel, quasi temps réel ou traitement par lots selon le besoin de décision.
• Le volume et l'historique : la profondeur de données réellement nécessaire à l'usage.
• La gouvernance et la qualité : le niveau de contrôle et de traçabilité qu'exige la criticité de l'usage.
• Le public servi : le nombre d'utilisateurs et leur niveau de compétence data.

Fraîcheur de la donnée : temps réel, quasi temps réel ou traitement par lots

La fraîcheur est la dimension la plus mal évaluée. Par réflexe, on vise le temps réel, alors que la grande majorité des usages s'en passe très bien. Un reporting mensuel, une analyse ad hoc, un modèle prédictif entraîné périodiquement se satisfont d'un traitement par lots, économique et robuste.

Distinguer les régimes de fraîcheur permet d'éviter de sur-architecturer en visant le temps réel là où il n'apporte rien. Seuls quelques usages, comme l'alimentation d'applications ou certaines détections, exigent réellement un flux continu. Pour tous les autres, le traitement par lots est le bon choix. La fraîcheur se dimensionne sur le besoin de décision, pas sur l'envie d'instantanéité.

Mal évaluer ce besoin coûte doublement : le temps réel inutile alourdit la plateforme et sa facture, tandis qu'un traitement trop lent sur un usage qui l'exige dégrade le service. L'ajustement précis de la fraîcheur à chaque usage est l'un des leviers d'économie les plus efficaces.

Volume, historique et profondeur d'analyse attendus

Chaque usage a un rapport différent au volume et à l'historique. Un reporting courant s'appuie sur un historique limité et des volumes maîtrisés. Un modèle prédictif peut exiger des années de données et de gros volumes pour être fiable. Une analyse ad hoc a besoin d'accéder à la donnée détaillée, mais pas nécessairement sur une longue profondeur.

Dimensionner le stockage et la puissance de traitement sur l'usage le plus gourmand, sans distinction, conduit à surpayer pour l'ensemble. À l'inverse, sous-dimensionner sur un usage qui exige de la profondeur le rend inopérant. La bonne approche consiste à évaluer le volume et l'historique réellement nécessaires usage par usage, puis à dimensionner sur cette base plutôt que sur une hypothèse maximaliste.

Niveau de gouvernance, de qualité et de traçabilité requis

Tous les usages n'appellent pas le même niveau de gouvernance. Un reporting réglementaire ou un usage critique exige une traçabilité complète, une qualité contrôlée, des responsabilités claires. Une exploration ponctuelle par un analyste averti peut se contenter d'un cadre plus souple, à condition de ne pas alimenter de décision engageante.

Le self-service, en particulier, relève le niveau d'exigence : mettre la donnée entre les mains des métiers suppose qu'elle soit fiable et cadrée en amont. Cette exigence rejoint la logique consistant à piloter ce qui compte plutôt qu'à tout mesurer : on concentre l'effort de gouvernance sur les usages où la fiabilité est critique, sans imposer partout le même niveau de contrôle. Ajuster la gouvernance à la criticité de l'usage évite à la fois le laxisme et la bureaucratie.

Nombre et profil des utilisateurs à servir

Un usage se caractérise enfin par son public : combien d'utilisateurs, avec quel niveau de compétence data. Un usage servant des centaines de consommateurs occasionnels appelle des interfaces simples et une donnée prête à l'emploi. Un usage servant quelques experts appelle un accès plus brut et plus flexible.

Ce paramètre détermine le niveau de préparation de la donnée et le type d'outils à prévoir. Servir des métiers non techniques suppose une donnée fortement préparée et des tableaux de bord clés en main. Servir des analystes suppose un accès à la donnée détaillée et des outils de manipulation. Confondre les deux publics conduit à des interfaces mal ajustées, trop complexes pour les uns ou trop rigides pour les autres. La distinction entre les besoins de la BI, de l'IA et du self-service tient largement à cette question du public servi.

Dimensionner une plateforme data sur les usages qui comptent vraiment

Recenser les usages, les hiérarchiser et traduire chacun en exigences aboutit à une décision : que la plateforme supporte, et dans quel ordre. C'est le moment où l'analyse se transforme en choix de conception. Trois principes guident ce dimensionnement.

Couvrir d'abord les usages critiques, ouvrir les autres ensuite

La priorité va aux usages critiques, ceux dont la défaillance coûte le plus cher. Une plateforme doit d'abord servir irréprochablement le reporting de pilotage, les usages réglementaires, les applications opérationnelles dont dépend le service. Ces usages justifient la robustesse, la disponibilité et la rigueur.

Les usages accessoires viennent ensuite, une fois le socle critique solide. Cette séquence évite de disperser l'effort initial sur des usages secondaires au détriment de l'essentiel. Une plateforme qui sert parfaitement trois usages critiques vaut mieux qu'une plateforme qui sert médiocrement dix usages mélangés. Ouvrir progressivement les usages accessoires, sur une base saine, est bien plus solide que de tout ouvrir d'emblée.

Éviter la sur-ingénierie en refusant les usages hypothétiques

La sur-ingénierie naît de l'anticipation d'usages qui n'existent pas encore. On dimensionne pour un temps réel dont personne n'a besoin, pour des volumes qui ne viendront peut-être jamais, pour des usages imaginés. Chaque anticipation ajoute de la complexité et du coût sans produire de valeur immédiate.

Refuser les usages hypothétiques ne signifie pas fermer l'avenir. Cela signifie ne pas payer aujourd'hui pour un besoin incertain de demain, tout en gardant une architecture capable d'évoluer. Une plateforme modulaire, comme une Modern Data Stack bien pensée, permet précisément d'ajouter une capacité quand un usage réel l'exige, sans l'avoir provisionnée d'avance. La sobriété initiale et l'ouverture à l'évolution ne s'opposent pas, elles se complètent.

Faire évoluer les usages supportés au rythme des besoins réels

Une plateforme n'est jamais figée. Les usages évoluent, de nouveaux apparaissent, d'autres disparaissent. Le bon réflexe n'est pas de tout prévoir dès le départ, mais de réévaluer régulièrement les usages supportés et d'ajuster le socle en conséquence. Ajouter un usage quand il devient réel, retirer un usage qui n'a plus de consommateur.

Cette évolution au fil de l'eau maintient la plateforme ajustée dans la durée. Elle évite deux dérives symétriques : la plateforme figée qui ne suit plus les besoins, et la plateforme qui accumule des usages morts sans jamais les retirer. Piloter les usages supportés dans le temps est ce qui garde une plateforme utile, sobre et gouvernable. C'est aussi ce qui relie ce dimensionnement aux choix d'architecture plus larges, ceux qui déterminent la capacité du socle à tenir dans la durée.

👉 À lire aussi : Architecture Data : comment faire des choix qui tiennent dans le temps ?