Arrêtez d'acheter des plateformes data. Réparez les flux que vous avez.

Fatigué de payer une plateforme data de plus pendant que la finance reconstruit encore le reporting hebdomadaire dans Excel ? Vous n'êtes pas seul. Les PME et ETI manquent rarement d'outils. Elles manquent de flux dont quelqu'un est propriétaire, qu'on surveille, et auxquels on fait confiance. Le réflexe, c'est d'acheter. La facture monte. Le tableur reste.

Vous connaissez déjà les symptômes

On repère la surdépense data sans ouvrir une seule facture. Quelqu'un en finance garde un tableur fantôme qui « marche vraiment, lui », parce que le dashboard payé a toujours un cycle de retard. Tous les 18 mois, un nouvel outil d'intégration est acheté pour faire le pont entre deux systèmes qui ne se parlent toujours pas. Et quand un chiffre paraît faux en comité de direction, la réponse est toujours « je vérifie avec l'IT » — jamais un chiffre net donné sur le moment.

Aucun de ces symptômes n'est un problème d'outillage. Ce sont des problèmes d'ownership déguisés en problèmes d'outils. Une plateforme ne peut pas réparer un flux dont personne n'est responsable. Elle lui donne juste une interface plus jolie et une facture plus lourde.

Où part vraiment l'argent

Trois causes reviennent systématiquement une fois qu'on regarde au-delà de la pile d'outils :

• L'empilement de licences : un outil de BI, un ETL, un catalogue, un reverse-ETL — chacun couvrant environ 60 % de ce dont vous avez besoin, avec 40 % de recouvrement, achetés à des moments différents par des personnes différentes pour éteindre des incendies différents.
• La reconstruction manuelle : les équipes ne font pas confiance à l'entrepôt, donc elles ré-exportent et reconstruisent les mêmes chiffres dans des tableurs chaque semaine. Ce n'est pas un échec de la BI. C'est un échec de confiance. Aucun dashboard ne répare la confiance.
• L'intégration sans propriétaire : la couche qui relie CRM, ERP et finance a été construite par un prestataire parti depuis, ou un script écrit « temporairement » il y a trois ans. Personne ne peut expliquer ce qui se passe si ça casse à 2 h du matin — donc personne n'y touche, y compris pour l'améliorer.

La comparaison que les éditeurs ne vous montrent jamais

Les éditeurs vendent contre votre douleur actuelle, pas contre l'alternative de réparer ce que vous avez déjà. Le slide deck, c'est toujours « notre plateforme vs votre chaos ». Jamais « notre plateforme vs une semaine à réparer l'ownership et l'alerting sur vos trois flux les plus critiques ». La deuxième option n'arrive presque jamais sur la table, parce que personne dans la salle n'est payé pour la suggérer.

Faites la vraie comparaison avant de signer. Prenez le coût total de la plateforme que vous êtes sur le point d'acheter — licence, onboarding, migration et heures internes de configuration. Puis estimez ce que coûterait de nommer un propriétaire, documenter les trois flux qui cassent le plus souvent, et ajouter des alertes basiques. Dans la plupart des PME et ETI, le deuxième chiffre est une fraction du premier — et il règle le problème que la plateforme était censée résoudre.

Un audit en trois étapes, faisable cette semaine

• Choisissez vos trois reportings les plus critiques — ceux qu'un dirigeant ouvre vraiment chaque semaine. Pas le catalogue complet. Juste les trois qui comptent.
• Remontez chaque champ de ces reportings jusqu'à son système source, étape par étape : chaque export manuel, chaque tableur, chaque copier-coller intermédiaire.
• Comptez les étapes manuelles sur chaque chemin. Zéro ou une, c'est correct. Deux ou plus, ce n'est pas un problème de licence — c'est une opportunité de build : quelque chose doit être automatisé, possédé, ou supprimé.

Cet audit prend deux ou trois jours pour une PME ou une ETI — pas la phase de découverte de plusieurs mois qu'un éditeur proposera de mener pour vous (généralement une mission payante qui se termine par une recommandation d'acheter sa plateforme).

Quand acheter une plateforme — et quand construire à la place

Acheter une plateforme est le bon geste quand vous avez atteint un vrai plafond de capacité — pas un problème de process déguisé en problème de capacité. C'est la minorité des cas qu'on rencontre. Dans la majorité, un build ciblé et petit — un pipeline correctement instrumenté, une consolidation réécrite avec des logs et un propriétaire — comble l'écart pour une fraction du coût de la première année d'un nouvel abonnement, sans nouvelle relation fournisseur à gérer pendant les cinq années suivantes.

Ce que ça donne concrètement

Une entreprise de distribution de taille moyenne avec laquelle on a travaillé avait quatre outils qui touchaient aux données de commande : l'ERP, une couche BI, un script de réconciliation fait maison, et un SaaS de reporting ajouté « temporairement » lors d'une migration système deux ans plus tôt. La finance reconstruisait encore le reporting de marge hebdomadaire à la main, parce qu'aucune des quatre sources ne s'accordait. La solution n'était pas un cinquième outil. C'était remonter le reporting de marge jusqu'à ses trois vraies sources, reconstruire un pipeline avec des logs corrects, nommer un propriétaire, et retirer complètement le SaaS de reporting. La reconstruction manuelle hebdomadaire a disparu — et l'abonnement dont personne ne se souvenait avoir souscrit aussi.

Commencez par l'audit, pas par la démo

Si une démo d'éditeur est plus familière à votre équipe que vos propres flux de données, c'est le signal à traiter en premier. Avant de demander une nouvelle démonstration produit, passez deux jours à mener l'audit ci-dessus sur vos trois reportings les plus critiques. Ce que vous trouverez vous dira — honnêtement — si le correctif est une plateforme, un build ciblé, ou simplement le fait de nommer quelqu'un propriétaire du flux que vous avez déjà.

Besoin d'un regard extérieur sur ces trois flux ? BastionLab propose un diagnostic pipeline à prix fixe : on cartographie les points de rupture et on vous laisse avec une recommandation motivée — qu'on construise la suite ou non. Si la question devient « posséder plutôt que louer la couche d'intégration », le positionnement produit est sur portlane.io : louer sa plateforme data.

FAQ

Comment savoir si notre entreprise surdépense en data ?

Trois symptômes : l'empilement de licences (plusieurs outils aux périmètres qui se recouvrent), des tableaux de bord que les équipes reconstruisent dans des tableurs faute de confiance dans l'entrepôt, et une couche d'intégration dont personne n'est vraiment propriétaire. Deux symptômes sur trois : vous payez des outils pour compenser un défaut d'ownership.

Faut-il acheter une plateforme data de plus ou construire ?

Réglez d'abord l'ownership et l'observabilité — cela supprime déjà l'essentiel de la surdépense. S'il reste un manque, un build ciblé et petit (un pipeline, une consolidation) bat généralement une nouvelle licence, parce qu'il supprime les étapes manuelles au lieu d'ajouter un outil par-dessus.

À quoi ressemble un audit data pragmatique ?

Prenez vos trois reportings les plus critiques, remontez chaque champ jusqu'au système source, et comptez les étapes manuelles sur chaque chemin. Plus de deux étapes manuelles : c'est une opportunité de build. L'audit tient en jours, pas en mois.

Une nouvelle plateforme n'est-elle pas plus rapide que de réparer nos flux existants ?

Elle donne cette impression, parce que quelqu'un vous en a fait la démo. En pratique, une nouvelle plateforme hérite des mêmes flux sans propriétaire — elle ajoute juste une couche par-dessus. La migration coûte souvent plus cher que ne l'aurait coûté la réparation, et le trou d'ownership est toujours là une fois le contrat signé.

Quelle est la première chose à changer en interne, avant même de toucher à un outil ?

Nommez un propriétaire par flux de données critique — quelqu'un qui est alerté quand ça casse, pas seulement quelqu'un qui reçoit un email. L'ownership est le correctif le moins cher de cette liste, et celui que toutes les entreprises en surdépense sautent.