Build vs buy : la grille de décision données

La question « build vs buy » appliquée aux données est rarement tranchée par un calcul. Elle l'est par réflexe : les équipes techniques construisent parce qu'elles savent construire, les équipes métier achètent parce qu'elles veulent aller vite. Les deux réflexes produisent des erreurs coûteuses, dans un sens comme dans l'autre. Voici une grille en quatre critères, volontairement froide, avec — parce que c'est plus utile qu'un plaidoyer — les cas où construire reste la bonne décision, y compris face à un fournisseur comme nous.

Critère 1 : la différenciation

La question centrale : si votre concurrent avait exactement les mêmes données, perdriez-vous votre avantage ? Si oui, la donnée fait partie de votre produit et vous devez en contrôler la collecte. Si non — si la donnée est un intrant, comme l'électricité —, la construire vous coûte sans vous distinguer. La quasi-totalité des données d'entreprises, de profils ou d'offres d'emploi sont des intrants : tout le monde peut y accéder, seule l'exploitation diffère. Construire un pipeline pour obtenir ce que le marché entier possède déjà, c'est payer le prix de la différenciation sans en obtenir les bénéfices.

Critère 2 : la volumétrie

En dessous de quelques milliers d'enregistrements, un stagiaire avec un tableur bat n'importe quel pipeline — construire est absurde, acheter souvent aussi. Au-delà de quelques centaines de milliers, les coûts d'infrastructure et de déduplication croissent plus vite que linéairement : c'est là que la mutualisation d'un fournisseur devient mathématiquement avantageuse. La zone intermédiaire, entre 10 000 et 100 000 fiches, est la seule où le calcul mérite d'être fait sérieusement, ligne par ligne.

Critère 3 : la fréquence de rafraîchissement

Une donnée collectée une fois — référentiels stables, historiques — supporte bien le build : le coût est un one-shot amortissable. Une donnée périssable — emails, postes occupés, offres d'emploi actives — impose un pipeline permanent, du monitoring et de la maintenance. Règle simplifiée : plus la donnée se périme vite, plus buy l'emporte, parce que vous n'achetez pas un stock mais un flux, et qu'un flux se mutualise.

Critère 4 : l'expertise interne

Un pipeline de collecte fiable exige des compétences précises : contournement anti-bot, normalisation, détection de dérive, conformité. Si personne dans l'équipe ne les possède, le coût réel du build inclut l'apprentissage — souvent six mois de production médiocre avant d'atteindre le niveau qu'un fournisseur offre au premier jour. À l'inverse, si cette équipe existe déjà chez vous pour d'autres raisons, le coût marginal du build chute, et la grille peut basculer.

Les cas honnêtes où build gagne

• La donnée est votre produit. Un comparateur de prix qui achèterait ses prix à un tiers n'a plus de raison d'exister.
• La source est propriétaire. Vos propres logs, vos interactions clients : personne ne peut les collecter à votre place.
• Le besoin est ultra-spécifique. Trois cents fiches très profondes sur un marché de niche : aucun agrégateur ne fera mieux qu'un humain motivé.
• La conformité l'exige. Certains secteurs imposent une chaîne de collecte auditable de bout en bout.

Dans ces quatre cas, construisez. Nous préférons vous le dire plutôt que de vous vendre un abonnement dont vous sortiriez déçu dans six mois.

Ce que la grille dit du reste

Pour tout le reste — données d'entreprises, de talents, d'écoles, d'offres d'emploi : volumineuses, périssables et non différenciantes —, les quatre critères pointent dans la même direction : achetez le flux, gardez votre ingénierie pour votre produit. C'est le créneau que sourcing.sh occupe : un index d'environ 200 000 entreprises, 123 000 profils, 98 000 écoles et 1,4 million d'offres, entretenu en continu par des agents et livré au forfait dans vos outils — CRM, ATS, API ou Claude via MCP. La couche base de données, pour que vous n'ayez à construire que la couche qui vous appartient vraiment.