Pour la plupart des organisations, l’achat est le meilleur choix, sauf si vous avez une équipe prête à assurer la maintenance du catalogue pendant des années. Développer une première version est rapide : une liste de tables, quelques définitions, un champ de recherche. Le vrai coût vient ensuite. Les connecteurs cessent de fonctionner lors des mises à jour de vos sources, les métadonnées deviennent obsolètes et quelqu’un doit continuer à assurer le suivi auprès des responsables. Le développement en interne ne vaut la peine que si vous avez un besoin auquel aucun produit ne répond et si vous pouvez y affecter durablement les ressources nécessaires.
Pourquoi développer en interne semble moins cher que cela ne l’est
La plupart des équipes comparent le développement et l’achat sur les premiers mois. Ce n’est pas la bonne période. Le développement est la partie facile. Le coût se situe dans tout ce qui vient après.
Prenons un exemple. L’équipe BI crée un glossaire dans SharePoint, avec un script qui parcourt chaque nuit les espaces de travail Power BI. Après quelques sprints, tout est en place. Tout le monde est satisfait. Six mois plus tard, une nouvelle source s’ajoute, une API change et le collègue qui a écrit le script quitte l’entreprise. Plus personne n’ose y toucher. Les définitions ne sont plus correctes et les équipes métier cessent de les consulter.
Ce n’est pas une mauvaise équipe. C’est le quotidien normal d’un logiciel développé en interne que personne ne gère comme un produit.
Ce qu’un catalogue de données doit réellement permettre
Une liste de tables ne suffit pas à faire un catalogue de données. Si vous le développez vous-même, vous devez aussi prévoir :
- Des connecteurs vers vos sources : Power BI, votre entrepôt de données, votre ERP. Chaque source possède ses propres API, qui changent régulièrement.
- Un scan automatique et une traçabilité des données, pour voir de quelle table provient chaque rapport, sans que quelqu’un doive tenir ces informations à jour manuellement.
- Des définitions et des responsables, avec un processus de validation et de révision.
- Des droits et des accès, pour que chacun ne voie que ce qu’il est autorisé à voir.
- Une fonction de recherche et une interface qu’un utilisateur métier comprend sans formation.
- Une visibilité sur la qualité des données, pour que le lecteur sache s’il peut se fier au chiffre du jour.
Chacun de ces éléments constitue un projet à part entière. Ensemble, ils forment un produit dont vous devez assurer la maintenance dans la durée.
Où se situe le coût après le lancement ?
Le coût d’un catalogue ne réside pas dans sa première version. Il réside dans le travail qui revient chaque mois.
- La technique. Les sources évoluent, les API changent, les mises à jour de sécurité doivent être appliquées. L’équipe qui développe est aussi responsable des mises à niveau.
- Le contenu. Les définitions deviennent obsolètes, les responsables changent de poste, de nouveaux rapports s’ajoutent. Sans suivi régulier, un catalogue devient une archive au bout d’un an.
- L’adoption. Les utilisateurs demandent de nouvelles fonctionnalités et un outil interne entre en concurrence avec toutes les autres priorités de l’équipe.
- Les connaissances. Souvent, seules une ou deux personnes savent exactement comment le catalogue fonctionne. Si elles partent, le catalogue part avec elles.
Un catalogue acheté vous décharge en grande partie de la technique. Le contenu reste toujours votre responsabilité. La question est donc aussi de savoir quel produit allège le plus ce travail sur le contenu.
Développement interne, open source ou achat : comment comparer ?
| Approche | Première version rapide | Qui assure la maintenance technique | Qui tient le contenu à jour | Adapté si |
|---|---|---|---|---|
| Développement interne (wiki, SharePoint, application maison) | Oui | Votre équipe, en permanence | Votre équipe | Le périmètre est limité et le reste |
| Catalogue open source auto-hébergé | Assez rapide | Votre équipe : hébergement, mises à niveau, connecteurs | Votre équipe | Vous avez une solide équipe de data engineering prête à en assurer la gestion |
| Suite de gouvernance d’entreprise | Non, le déploiement est souvent long | Le fournisseur | Les data stewards et une équipe de gouvernance | Vous disposez d’une organisation de gouvernance étendue ou la mettez en place |
| Catalogue léger visible dans vos rapports | Oui | Le fournisseur | Les responsables désignés, dans le cadre de leur travail | Les équipes métier veulent surtout comprendre les rapports et pouvoir s’y fier |
Quand développer en interne est une bonne idée
Développer en interne n’est pas toujours une erreur. Cela peut être le bon choix si :
- vous avez une ou deux sources et cela ne changera pas ;
- votre équipe de data engineering souhaite gérer un catalogue comme un produit, avec du temps et un budget pour la maintenance ;
- vous avez une exigence très spécifique à laquelle aucun produit ne répond et cette exigence prime sur tout le reste.
En cas de doute, commencez par vous demander qui gérera le catalogue dans deux ans. Si vous ne pouvez pas donner de nom, le développement en interne représente un risque.
Cinq questions avant de décider : Objectif, Lecteurs, Sources, Maintenance, Responsabilités
- Objectif : quel problème le catalogue résout-il et comment saurez-vous qu’il est résolu ?
- Lecteurs : s’agit-il de data engineers, d’analystes ou d’utilisateurs métier qui consultent des rapports ?
- Sources : combien de systèmes devez-vous connecter et à quelle fréquence évoluent-ils ?
- Maintenance : qui s’occupe des connecteurs, des mises à niveau et de la sécurité, aujourd’hui et dans deux ans ?
- Responsabilités : qui tient les définitions à jour et cette tâche s’intègre-t-elle dans le travail habituel de ces personnes ?
Où se situe dScribe
dScribe est un catalogue de données à acheter plutôt qu’à développer, conçu pour les organisations qui veulent avant tout que les équipes métier comprennent leurs rapports. Dans Power BI, l’extension de navigateur affiche les définitions et les responsables directement sur les rapports que votre équipe consulte déjà, ainsi que les échecs d’exécution sous forme d’alertes. Les problèmes de qualité des données sont regroupés au même endroit, dans une marketplace au sein de l’application dScribe. dScribe lit uniquement les métadonnées, vos données elles-mêmes ne sont pas déplacées. Il parcourt les métadonnées de vos systèmes, y compris les plus anciens, et en dresse un inventaire, pour que votre équipe n’ait pas à entretenir ses propres connecteurs. Pour le travail sur le contenu, des suggestions intelligentes vous aident à définir les termes et les KPI, les relient aux rapports et aux jeux de données dans lesquels ils semblent être utilisés, repèrent les doublons et contribuent à établir la traçabilité des données. La définition des KPI reste en partie manuelle, mais les suggestions allègent ce travail.
Pour conclure
La question n’est pas de savoir si vous pouvez développer un catalogue de données. Presque toutes les équipes BI en sont capables. La question est de savoir si vous voulez en assurer la maintenance, chaque mois, même après le départ de la personne qui l’a développé. Ne comparez donc pas la première version, mais la deuxième année. C’est la personne qui assurera encore le suivi technique et la mise à jour des définitions à ce moment-là qui déterminera si votre catalogue reste vivant ou devient une archive.
Questions fréquentes
Combien coûte le développement d’un catalogue de données en interne ?
Le développement représente rarement la plus grande part du coût. Comptez aussi les personnes qui s’occuperont des connecteurs, des mises à niveau, de la sécurité et des demandes des utilisateurs dans les années à venir. Ce travail se poursuit aussi longtemps que le catalogue existe.
Un catalogue de données open source est-il gratuit ?
Le logiciel, oui. Son utilisation, non. Vous devez l’héberger, le mettre à niveau, le connecter à vos sources et assurer son support. Cela demande une équipe pour laquelle ces tâches font partie des responsabilités permanentes.
Ne pouvons-nous pas simplement utiliser Excel ou SharePoint comme catalogue de données ?
Pour une première liste de définitions, oui. Le problème est qu’une telle liste reste déconnectée de vos rapports et de vos sources, ce qui la rend obsolète et peu consultée. Dès que vous avez besoin de scans automatiques, de traçabilité ou de visibilité sur la qualité des données, vous en atteignez les limites.
Quand vaut-il mieux acheter un catalogue de données que le développer ?
Lorsque vous avez plusieurs sources, que les équipes métier doivent utiliser le catalogue et que vous n’avez pas d’équipe prête à en assurer la maintenance comme un produit. C’est le cas dans la plupart des moyennes et grandes organisations.
Comment démarrer avec un catalogue de données sans lancer un grand projet ?
Choisissez un domaine et quelques rapports très consultés. Convenez des définitions et des responsables pour ce périmètre, puis rendez-les visibles là où les utilisateurs consultent les informations. N’élargissez le périmètre qu’une fois ce domaine bien vivant.