Build vs buy d'une plateforme décisionnelle : le vrai cadre

La plupart des enseignes abordent la question du build vs buy en position de force apparente. Vous avez déjà un entrepôt de données, plusieurs années d'historique transactionnel propre, et une équipe data science qui a livré des modèles de prévision qui marchent. Ajouter une couche de décision par-dessus ressemble à un pas incrémental — un trimestre d'ingénierie, peut-être deux. Le réflexe est donc de construire en interne, et en surface ce réflexe est rationnel. Cet article ne plaide pas contre ; il vous donne le cadre pour savoir si le réflexe tient une fois sorti du POC, en production.

Ce que prouve le POC interne (et ce qu'il masque)

Le proof of concept interne est rapide, peu coûteux, et presque toujours convaincant. Votre équipe extrait une saison de ventes et de stock de l'entrepôt et entraîne un modèle sur une catégorie. Quelques centaines de lignes transforment la prévision en recommandation de démarque ou de réapprovisionnement. Trois semaines plus tard, vous avez un notebook qui produit des décisions plausibles sur des données réelles. La démonstration en comité est excellente.

Ce que le POC prouve est étroit mais réel : vos données sont assez bonnes, et la modélisation n'est pas la partie difficile. Cette conclusion est juste. Mais décidez que le reste n'est « que de l'ingénierie » et vous reproduisez l'échec le plus répandu du retail — les trois erreurs classiques des projets data.

Car le POC tourne dans des conditions qui n'ont rien à voir avec la production. Une catégorie, pas quarante. Une saison, calculée une fois, pas un flux continu recalculé chaque jour. Un data scientist qui nettoie l'entrée à la main, pas une chaîne automatisée tolérante à un flux WMS qui arrive en retard ou malformé. Les recommandations atterrissent dans un tableur qu'un humain lit, pas dans l'ERP sur lequel un responsable de magasin agit avant mardi matin.

Le POC répond à « sait-on calculer une bonne décision ? ». La production doit en trancher une plus dure. Sait-on calculer la bonne décision sur chaque couple SKU/magasin, chaque jour, la propager vers les systèmes qui l'exécutent, et apprendre de ce qui s'est passé ? Ce sont deux questions différentes, et c'est dans leur écart que le build interne s'enlise.

Les trois endroits où le build interne s'enlise

Quand un build interne de couche de décision se bloque, c'est rarement le modèle. C'est l'un — souvent les trois — des points suivants.

1. L'intégration continue aux systèmes opérationnels

Le POC lit dans l'entrepôt et écrit dans un fichier. La production doit lire et écrire dans la stack opérationnelle vivante : ERP, WMS, moteur de pricing, plateforme e-commerce, outil de planning. Chacun est une intégration bidirectionnelle qui doit tourner chaque jour, survivre aux pannes partielles, et réconcilier des données qui se contredisent d'un système à l'autre.

Ce n'est pas de la data science. C'est de l'ingénierie système, et c'est la partie que personne ne chiffre pendant le POC. Une décision de démarque qui ne sait pas réécrire dans le moteur de pricing reste un tableur — exactement l'impasse qui rend les données retail inutiles sans couche de décision.

Les équipes sous-estiment couramment cet effort d'un facteur trois ou quatre. Les intégrations sont reportées de trimestre en trimestre, les exports manuels comblent le vide, et les « quelques semaines d'ingénierie » deviennent discrètement une roadmap à part entière.

2. La maintenance de la couche de règles métier dans le temps

Toute décision retail repose sur des règles métier : facings minimum, tailles de colisage fournisseur, listes never-out-of-stock, planchers de démarque en fin de vie, contraintes de cluster magasins, fenêtres d'exclusivité. Dans le POC, vous codez en dur la poignée qui compte pour une catégorie. En production, il y en a des centaines, elles diffèrent par catégorie et par pays, et elles changent en permanence — chaque saison, chaque réorganisation d'acheteurs, chaque nouveau contrat fournisseur.

Un jeu de règles codé en dur est une photo qui devient fausse en une saison. Une couche de règles maintenable — où un category manager change une contrainte sans déploiement de code — est un vrai produit à concevoir, pas un fichier de configuration. Nous décortiquons cet enjeu dans pourquoi 80 % des règles métier retail sont mal utilisées.

Sous-estimez ce point et vous obtenez l'échec classique. Le modèle produit des recommandations que les opérations rejettent, parce que les règles du moteur ne correspondent plus à celles dans leur tête. L'adoption s'effondre, et le build ressemble à un problème de modèle alors que c'est un problème de maintenance.

3. La fermeture de la boucle exécution-apprentissage

Le POC produit une décision. Il n'observe pas si la décision a été exécutée, si elle a marché, et ne réinjecte rien dans le cycle suivant. Fermer cette boucle — décision, exécution, résultat, apprentissage — est ce qui sépare un moteur de recommandation d'une plateforme de décision.

La construire suppose de capter le retour d'exécution depuis les systèmes opérationnels, d'attribuer les résultats, et de les réinjecter sans qu'un humain recolle des tableurs. C'est la plus difficile des trois à construire et la plus facile à reporter. D'où le fait que la plupart des systèmes internes plafonnent en recommandeurs unidirectionnels qui ne s'améliorent jamais.

Quand construire a réellement du sens

Acheter n'est pas toujours la réponse, et prétendre le contraire serait malhonnête. Il existe des conditions réelles où construire la couche de décision en interne est le bon choix.

Construisez quand le décisioning est votre différenciation concurrentielle centrale. Le test : est-ce votre logique de pricing ou d'allocation qui vous fait gagner le marché — pas votre produit, pas vos magasins, mais le moteur de décision lui-même ? Si oui, le maîtriser de bout en bout est stratégique. On n'externalise pas son avantage.

Construisez quand vous pouvez financer une équipe produit permanente, pas une équipe projet. Une plateforme de décision n'est pas un projet qui se livre et se termine. C'est un produit qui demande de l'ingénierie continue : nouvelles intégrations, évolution de la couche de règles, maintenance de la boucle. Si vous savez staffer et retenir une équipe dédiée pendant des années — des ingénieurs plateforme, pas des data scientists empruntés — construire est viable.

Construisez quand votre stack opérationnelle est réellement atypique. Si vos systèmes sont si propriétaires qu'aucune plateforme ne s'intègre proprement, l'avantage d'intégration de l'achat se réduit. La thèse du build s'en trouve renforcée.

Si aucune de ces trois conditions ne tient, construire reviendra probablement à recréer des capacités qui existent déjà — lentement, et plus cher. C'est le cas quand le décisioning est nécessaire mais n'est pas votre différenciation, quand vous staffez un projet plutôt qu'un produit, quand votre stack est conventionnelle. Ce n'est pas un échec de votre équipe. C'est une mauvaise lecture de la nature réelle du travail.

La vraie question : le coût total d'industrialisation, pas le coût du POC

Le débat build vs buy est presque toujours mal cadré. On compare le coût du POC — quelques semaines d'un data scientist — à la licence annuelle d'une plateforme. Sur cette comparaison, construire gagne toujours. Mais le POC n'est pas le coût. L'industrialisation est le coût, et elle est invisible au moment où vous décidez.

La comparaison honnête est le coût total de possession sur cinq ans d'une couche de décision en production :

• L'ingénierie d'intégration pour connecter chaque système opérationnel, en bidirectionnel, et le maintenir en fonctionnement
• Le travail produit pour bâtir et maintenir une couche de règles métier éditable, à travers catégories et pays
• L'ingénierie plateforme pour fermer et opérer la boucle exécution-apprentissage
• L'équipe permanente qui possède tout cela, année après année, y compris le coût du turnover
• Le coût d'opportunité de chaque saison passée à construire de la tuyauterie plutôt qu'à améliorer les décisions

Face à ce chiffre, la licence de la plateforme est rarement l'option chère. L'option chère, c'est le build qui consomme deux ans de vos meilleurs ingénieurs et livre en retard. Il arrive en recommandeur unidirectionnel que les opérations ne croient pas — le cimetière des projets data que le POC faisait paraître impossible.

La question à poser sur la table n'est pas « sait-on le construire ? ». Vous le savez presque certainement. C'est « devons-nous posséder l'industrialisation et la maintenance d'une plateforme de décision pour les cinq prochaines années — ou cet effort est-il mieux investi dans les décisions elles-mêmes ? ».

La conclusion honnête

Construisez si le décisioning est votre avantage, si vous pouvez financer une équipe produit sur la durée, et si votre stack met en échec toutes les plateformes. Sinon, acheter la couche et pointer votre équipe data vers les décisions — pas vers la tuyauterie — est presque toujours le choix à plus fort levier. Une fois penché vers le buy, notre guide d'achat détaille les critères, et notre comparatif conseil vs plateforme cadre la question parallèle que tout DAF pose ensuite. Le POC n'a jamais été l'enjeu. L'industrialisation l'a toujours été.

Pour les questions de ROI et de budget que les DAF posent lors de l'évaluation d'une plateforme, voir notre FAQ DAF.

---

Mettez votre arbitrage build vs buy à l'épreuve

Chez Solya, nous proposons un diagnostic de 30 minutes aux directions data et opérationnelles. Objectif : confronter un arbitrage build vs buy à votre contexte — votre stack, votre équipe, votre complexité de règles. Pas de pitch générique, mais une lecture honnête de ce qui, du build ou du buy, colle à votre situation.

Vous repartez avec :

• Une estimation réaliste du coût d'industrialisation sur cinq ans d'un build interne
• Une cartographie des endroits où votre stack et votre complexité de règles aideraient ou pénaliseraient un build
• Une lecture claire de savoir si le décisioning est assez différenciant pour justifier de le posséder