FAQ DSI — intégrer un moteur décisionnel retail
Les réponses pour les DSI et CIO sur l'intégration d'une plateforme décisionnelle retail : architecture, ERP, API, sécurité, SLA, cloud et lock-in.
Un moteur décisionnel se pose entre la couche data et les systèmes d'exécution. Il lit les données agrégées depuis l'entrepôt ou le lakehouse et calcule les décisions. Il les réécrit ensuite dans le WMS, l'OMS, le POS ou l'ERP via REST ou via une queue. Le côté exécution reste stateless et le système de référence reste intact. La plupart des retailers font tourner la plateforme en sidecar de l'infrastructure existante, pas en remplacement. Cela garde un blast radius réduit et un rollback peu coûteux. Voir notre guide d'intégration d'un moteur décisionnel pour l'architecture de référence complète.
L'intégration suit un de deux patterns. En lecture seule, la plateforme consomme la donnée ERP et présente les décisions dans une UI séparée, livrable en huit à douze semaines. En écriture, les décisions reviennent dans l'ERP pour exécution, et le délai grimpe à seize-vingt-quatre semaines. La rallonge tient à l'alignement des données de référence et au change-management côté SAP ou Oracle, pas à la plateforme elle-même. La plupart des équipes démarrent en lecture pour prouver la valeur, puis passent en écriture une fois la confiance acquise. Voir notre page intelligence layer pour le flux de retour dans l'ERP.
La surface d'API se range en trois catégories. Les endpoints inbound gèrent l'ingestion des données depuis l'entrepôt, le WMS et le POS. Les endpoints de décision permettent aux systèmes aval de récupérer la décision courante pour un SKU, un magasin ou une commande. Les endpoints feedback acceptent les données d'exécution réelles pour que la plateforme boucle la boucle sur la précision. L'ensemble tient en REST plus webhooks, intégralement documenté en OpenAPI. Le contrat est versionné, donc une intégration ERP écrite aujourd'hui continue de fonctionner après les évolutions futures. Voir notre page orchestration layer pour la cartographie d'API complète.
La plupart des données décisionnelles retail sont agrégées et ne portent pas de PII, ce qui simplifie nettement la posture sécurité. Les exigences standards restent valides : SOC 2 Type II, ISO 27001 et résidence européenne pour le périmètre RGPD. S'y ajoutent le chiffrement en transit et au repos, le SSO via SAML ou OIDC, et le contrôle d'accès par rôle. Solya tourne en régions européennes uniquement, sans transfert hors UE. Tout éditeur évalué doit publier sa liste de sous-traitants et permettre au RSSI de relire un rapport de pen-test récent. Voir notre article souveraineté et RGPD pour la posture de conformité complète.
Le cloud-native reste la voie par défaut et la moins coûteuse. Le on-prem reste techniquement possible mais ajoute typiquement trente à cinquante pourcent de TCO sur trois ans. Le retailer reprend alors l'infrastructure, le patching et le réentraînement modèle à sa charge. Le cloud privé, où la plateforme tourne dans votre VPC AWS, Azure ou GCP, est le terrain du milieu. Il satisfait la plupart des retailers régulés sans l'overhead du on-prem. Le choix dépend surtout de votre posture cloud existante et de l'appétit du RSSI pour le risque tenant partagé.
Au-dessus d'eux, pas en parallèle. La plateforme décisionnelle produit le plan optimisé, le WMS et l'OMS l'exécutent. Le WMS garde la mécanique entrepôt : slotting, picking et putaway. L'OMS garde le routing et le fulfilment des commandes. La plateforme alimente les deux avec des entrées plus intelligentes : meilleurs objectifs d'allocation, meilleures quantités de réassort, meilleures priorités de routing. Cette séparation garde chaque système dans son couloir et rend les changements d'éditeur tractables. Voir notre article WMS vs plateforme décisionnelle pour le partage de responsabilités complet.
Pour un retailer mid-market avec un entrepôt de données propre, comptez douze à vingt semaines de bout en bout. La répartition tourne autour de quatre semaines d'intégration data, puis quatre à six semaines de calibrage modèle sur votre historique. Ajoutez quatre semaines de validation métier en shadow, et deux à quatre semaines de déploiement par paliers. Les délais compressés de huit à dix semaines sont atteignables sur un modèle de données propre et un scope mono-décision. Les scopes multi-décisions ou une donnée référentielle bruitée poussent vers le haut de la fourchette.
Les SLA de production tournent autour de quatre-vingt-dix-neuf virgule cinq à quatre-vingt-dix-neuf virgule neuf pourcent d'uptime, selon le tier. La fraîcheur des décisions compte plus que l'uptime brut pour la plupart des cas d'usage. Le réassort rafraîchit à l'heure, l'allocation au jour, la démarque à la semaine. Le décisionnel temps réel sous la seconde reste rarement utile en dehors du pricing dynamique, et l'imposer gonfle le coût sans changer le P&L. Le contrat doit préciser des fenêtres de fraîcheur par type de décision, pas juste un chiffre global d'uptime. Voir notre plongée architecture pour les tiers de fraîcheur typiques.
Le lock-in est réel mais gérable via trois clauses contractuelles. Première clause, la portabilité de la donnée : un engagement écrit que votre historique, features et labels inclus, est exportable à la demande. Deuxième clause, la portabilité modèle : modèles entraînés exportables dans un format standard comme ONNX, pour qu'un éditeur successeur puisse les évaluer. Troisième clause, une API basée sur des standards, REST et OpenAPI, pas un SDK propriétaire. Exigez les trois dans le contrat de prestations avant signature. Voir notre article build vs buy pour le cadre qui chiffre le risque lock-in dans la décision globale.
Une plateforme bien conçue est multi-tenant dès le jour un. Chaque marque ou région devient un tenant logique avec ses propres données, paramètres et contrôles d'accès, servi depuis un seul déploiement de production. Cela garde l'exploitation simple et permet d'ajouter une marque ou un pays en semaines, pas en trimestres. Évitez les plateformes qui exigent une instance séparée par tenant. Elles passent bien à une ou deux marques et deviennent ingérables à cinq ou plus. Vérifiez l'isolation tenant, le tuning modèle par tenant et les logs d'audit par tenant pendant l'évaluation technique.