Construire ou acheter sa plateforme data : sur quels critères trancher ?

Pour trancher entre construire et acheter sa plateforme data, quatre critères suffisent : la spécificité des usages à servir, la capacité réelle à exploiter ce qui sera construit, le coût de sortie si le choix se révèle mauvais, et la trajectoire de la facture quand les volumes montent. Ces critères s’appliquent composant par composant, jamais à la plateforme entière.

La question « construire ou acheter » revient à chaque projet de plateforme data, et elle est presque toujours posée trop tôt et trop largement. Trop tôt, parce qu’elle est tranchée avant que les usages à servir soient connus. Trop largement, parce qu’elle porte sur la plateforme entière alors qu’une plateforme est un assemblage de composants très inégaux.

Le stockage, l’ingestion de sources courantes, la supervision ou la gestion des accès sont des briques que le marché fournit en grand nombre et à maturité. Le calcul d’un indicateur propre à un métier, une règle de rapprochement ou un modèle de scoring ne se trouvent en revanche sur aucune étagère. Traiter ces deux familles avec la même réponse conduit soit à reconstruire ce qui existe, soit à plier un besoin singulier à un produit générique.

Les arbitrages qui tiennent dans la durée reposent sur un petit nombre de critères, posés dans le bon ordre et appliqués brique par brique. Quatre d’entre eux suffisent, et leur croisement permet de repérer rapidement les erreurs les plus fréquentes.

Ces critères servent de point de départ à une revue d’architecture. Ils ne remplacent pas une analyse chiffrée, qui dépend du contexte, du niveau de maturité de l’équipe et des contraintes réglementaires de chaque organisation.

Pourquoi la question se pose composant par composant

Une plateforme data regroupe des fonctions qui n’ont ni la même valeur différenciante ni le même coût de maintien. Un orchestrateur, un entrepôt, un outil de supervision et une couche de calcul des indicateurs ne relèvent pas de la même logique de décision. La première étape consiste donc à découper la plateforme en briques, puis à poser les quatre critères sur chacune d’elles.

Ce découpage se fait à partir des usages et non à partir des outils. Les usages qui comptent, leur criticité et leur fréquence d’évolution déterminent ce que la plateforme doit réellement faire, comme le détaille l’article sur les usages qu’une plateforme data doit réellement supporter. Une brique qui ne sert aucun usage prioritaire n’a pas à faire l’objet d’un arbitrage.

Premier critère : la spécificité des usages à servir

Le premier critère mesure l’écart entre ce que le marché propose en standard et ce que l’usage exige. Plus l’usage est propre à l’organisation, moins un produit du marché le couvre sans contournement. Plus il est courant, plus l’achat est cohérent, parce que l’éditeur a déjà absorbé le coût de conception sur de nombreux clients.

Trois questions permettent de situer un composant sur cet axe :

• Le besoin existe-t-il à l’identique dans d’autres organisations du même secteur ?
• La logique à implémenter relève-t-elle d’une règle métier propre à l’organisation, ou d’une fonction technique courante ?
• L’usage évoluera-t-il plus vite que le cycle de livraison d’un éditeur ?

Un composant standard sur ces trois questions s’achète presque toujours. Un composant spécifique sur les trois appelle une construction, à condition que le deuxième critère soit satisfait.

Deuxième critère : la capacité réelle à exploiter ce qui sera construit

Construire un composant n’est que le début de son cycle de vie. Il faut ensuite le maintenir, le faire évoluer, le documenter, le surveiller et former les personnes qui le reprendront. La capacité à porter ce cycle dépend du nombre de data engineers disponibles, de leur expérience et de la part de leur temps qui reste libre une fois les demandes courantes traitées.

Ce critère se mesure sur trois points concrets.

• Le nombre de personnes capables de reprendre le composant en cas de départ de son auteur.
• Le temps réellement disponible pour la maintenance, une fois les demandes des métiers traitées.
• L’existence d’une documentation et de tests suffisants pour qu’une reprise ne dépende pas d’une seule personne.

Une capacité insuffisante ne condamne pas la construction de tout composant spécifique. Elle impose en revanche de réduire le périmètre construit à ce qui ne peut pas être acheté, et d’acheter le cadre technique autour. Le risque inverse, une équipe qui sait construire mais dont la capacité est mieux employée ailleurs, est traité plus bas. Les effets d’une plateforme trop lourde pour l’équipe qui la porte sont décrits dans l’article sur la complexité d’une plateforme data face à la gouvernance.

Troisième critère : le coût de sortie

Le coût de sortie désigne tout ce qu’il faudrait engager pour quitter un choix devenu inadapté : migration des données, réécriture des traitements, reprise des habilitations, formation des équipes et période de fonctionnement en double. Il existe pour la construction comme pour l’achat, sous des formes différentes.

Côté achat, le coût de sortie dépend du format des données, de la possibilité de les exporter sans perte et de la portabilité des traitements. Côté construction, il dépend de la dépendance à des bibliothèques ou à des personnes. Un composant construit sur des briques ouvertes et documenté se remplace plus facilement qu’un produit fermé, mais seulement si cette documentation existe.

Le cadre réglementaire renforce l’intérêt de ce critère. Le règlement européen sur la résilience opérationnelle numérique (DORA) prévoit, pour les entités financières qui externalisent des fonctions critiques ou importantes auprès de prestataires de services TIC, des stratégies de sortie. Le règlement européen sur les données (Data Act) impose de son côté des conditions de changement de fournisseur pour les services de traitement de données, dont le cloud. Ces textes ne dispensent pas d’analyser son propre contexte, mais ils placent la réversibilité parmi les exigences à documenter dès le choix initial.

Documenter ce choix et ses hypothèses est une pratique à part entière : l’article sur la documentation des décisions d’architecture explique comment conserver la trace du raisonnement pour qu’il survive aux équipes qui l’ont produit.

Quatrième critère : la trajectoire de la facture

Le coût initial d’un choix renseigne peu sur son coût total. Une solution achetée peut présenter une facture modeste au démarrage, puis croître avec les volumes, le nombre d’utilisateurs ou la fréquence des traitements. Une solution construite suit la courbe inverse : un investissement initial élevé, puis une charge plutôt stable, mais qui dépend du temps de maintenance. Ces mécanismes sont détaillés dans l’article sur les coûts d’une architecture data.

La question utile n’est donc pas « combien coûte ce composant aujourd’hui ? », mais « comment sa facture évolue-t-elle si les volumes, les utilisateurs et les usages doublent ? ». Cette projection se fait avec des hypothèses explicites, revues régulièrement, et non à partir d’une valeur unique.

Quatre postes méritent d’être comptés pour chaque option.

• Le coût d’acquisition ou de développement initial.
• Le coût récurrent : licences, consommation, hébergement, maintenance.
• Le coût de croissance : ce qui change quand les volumes ou les utilisateurs augmentent.
• Le coût de sortie, vu précédemment, à provisionner même s’il n’est jamais engagé.

Comparer construire et acheter sur les quatre critères

Chaque option se comporte différemment sur les quatre critères, et aucune ne l’emporte de façon générale, car la réponse dépend du composant considéré.

Croiser spécificité et capacité de l’équipe

Les deux premiers critères se croisent dans une matrice à quatre situations. Les deux autres, coût de sortie et trajectoire de la facture, servent ensuite à départager les cas où la matrice laisse un doute. Chaque quadrant appelle une réponse de départ et une priorité.

Le quadrant des composants standards pour une équipe à forte capacité est celui où l’erreur est la plus fréquente. L’équipe sait construire, la tentation de le faire est réelle, et la capacité consacrée à reconstruire un composant courant n’est plus disponible pour la qualité, la modélisation ou la gouvernance. À l’inverse, le quadrant des composants spécifiques pour une équipe à faible capacité impose de réduire le périmètre construit au strict nécessaire.

Cette lecture en quadrants complète une analyse plus large du choix d’architecture. La question de l’adéquation d’une pile d’outils à la taille de l’organisation est approfondie dans l’article sur les organisations auxquelles s’adresse une Modern Data Stack, et le choix concret des outils dans celui sur les outils pour initier une Modern Data Stack pragmatique.

Les erreurs fréquentes dans l’arbitrage

Quatre erreurs reviennent régulièrement dans les décisions mal calibrées, et chacune correspond à un critère négligé.

• Décider sur la plateforme entière plutôt que brique par brique, ce qui impose une réponse unique à des composants très différents.
• Comparer un coût de développement à un prix de licence sans compter la maintenance, l’exploitation et la formation.
• Choisir un produit sans avoir vérifié la possibilité d’exporter ses données et ses traitements.
• Ne pas prévoir de revue, alors que les volumes, les usages et l’équipe évoluent.

Une pile acquise sans tenir compte de la capacité d’exploitation produit un autre type de difficulté, développé dans l’article sur la scalabilité organisationnelle d’une Modern Data Stack. Lorsque l’arbitrage initial ne tient plus, la question d’une reprise partielle se pose, traitée dans l’article sur la refonte de l’architecture data.

Documenter l’arbitrage et le revoir

Un arbitrage construire ou acheter n’est pas définitif. Il repose sur des hypothèses qui évoluent : volumes, taille de l’équipe, offre du marché, exigences réglementaires. Il gagne donc à être consigné avec ses hypothèses, ses critères de revue et une date de réexamen. La définition de l’architecture cible à partir des usages, décrite dans l’article sur l’architecture des données cible, fournit le cadre dans lequel ces revues s’inscrivent.

Trois déclencheurs justifient en général de rouvrir la décision.

• Un écart marqué entre la facture prévue et la facture constatée.
• Un changement dans l’équipe qui modifie la capacité réelle de maintenance.
• Un nouvel usage qui ne rentre plus dans le périmètre prévu.

À retenir

Cinq points résument la démarche.

• Découper la plateforme en composants avant de décider.
• Évaluer chaque composant sur quatre critères : spécificité, capacité de l’équipe, coût de sortie, trajectoire de la facture.
• Acheter les composants standards, même lorsque l’équipe sait les construire.
• Construire les composants spécifiques seulement si quelqu’un peut les maintenir dans la durée.
• Vérifier la sortie avant de s’engager et réexaminer l’arbitrage à intervalle régulier.