Go back to Market Research
Vekia is a cloud application for demand forecasting, inventory management, and replenishment. It calculates order proposals, identifies shortage risks, monitors logistics flows, and connects these functions to customers’ existing transactional systems. Its applications include retail replenishment and spare-parts supply. (1, 7, 8)
Overall supply chain score: 5.0/10.
| Dimension | Score |
|---|---|
| Supply chain depth | 5.6/10 |
| Decision and optimization substance | 5.8/10 |
| Product and architecture integrity | 4.2/10 |
| Technical transparency | 5.0/10 |
| Vendor seriousness | 4.4/10 |
Vekia addresses concrete ordering decisions and explicitly recognizes uncertainty in both demand and delivery times. Its customer cases report substantial automation. The unresolved technical issue is how broadly those uncertainties enter the economic calculation across products and locations. The public research exposes more restrictive formulations than the current promise of maximal optimization for any supply chain or data volume. (2, 8, 5)
Business continuity is also an immediate concern. On September 28, 2026, the Lille Métropole commercial court terminated Vekia’s safeguard plan and opened court-supervised reorganization proceedings, or redressement judiciaire. The observation period runs to March 28, 2027. For a service that calculates recurring replenishment decisions, continuity of hosting, support, and model maintenance belongs in the purchasing decision alongside numerical performance. (20)
Vekia versus Lokad
Both vendors aim to replace repetitive replenishment calculations with software. Vekia supplies a packaged application: forecasts, stock settings, prioritized proposals, and review screens. Its Engine offer also presents forecasting and order automation as an addition to the existing ERP. (1, 17)
Lokad’s inventory optimization centers on a maintained numerical model of the customer’s decisions. Demand and supply uncertainty, economic consequences, and operational restrictions are brought into that model; Supply Chain Scientists develop and maintain the calculation. The intended output is an economically ranked set of actions, with human effort concentrated on improving the decision process. This is the broader design perspective developed in Introduction to Supply Chain.
The practical distinction concerns what happens when a recommendation is wrong. A packaged system can invite an override, a changed threshold, or a different supplier setting. A maintained decision model should turn the failure into a revised calculation and retest its effects across the operation. Vekia exposes configuration and explanation features, but little public detail about this second loop. Its value therefore depends partly on how much recurring correction remains with the customer’s team. (3, 15)
Technology history and follow-through
Vekia’s record spans more than a decade of forecasting and replenishment work. Its company history dates the business to 2008, the move from consulting to software to 2010, and its SaaS transition to 2018. The early AI positioning concerned numerical prediction and ordering, well before the present generation of language-model agents. (11)
| Period | Public evidence | Significance |
|---|---|---|
| 2014 | Manuel Davy’s University of Lille presentation describes daily stock decisions, sparse product/store sales, logistics capacities, and a calculation window of a few hours. | The original problem was operationally specific. (12) |
| 2016 | Asys acquires VekiaPlan and its personnel-planning team. | This was the workforce-planning product, rather than the acquisition of Vekia’s replenishment business. (13) |
| 2019–2021 | Published Okaidi and Engie cases describe replenishment workloads and reported results. | They establish applied deployments behind the machine-learning story. (9, 8) |
| 2021 | Engine launches with probabilistic forecasting, ERP integration, and a claimed 25% improvement over the previous generation. | The improvement has no published metric or test protocol. (11) |
| 2024 | A Vekia-backed doctoral thesis studies multi-echelon replenishment. | It exposes algorithms, restrictive assumptions, and unresolved industrialization work. (5) |
| 2025–2026 | Current pages emphasize probabilistic AI and a scalable APS; the application job posting names three database platforms. | The broader promise needs a corresponding account of numerical scope and infrastructure cost. (2, 6) |
The 2021 machine-learning article illustrates the gap between a useful idea and an overextended explanation. It correctly moves away from predicting one certain future, but then describes selecting the most probable scenario and the one fitting business objectives. That leaves the decisive question unanswered: are actions valued across possible outcomes, including expensive low-probability failures, or selected against one preferred future? The same article reports an anonymous promotion experiment with 26% higher revenue and 42% less residual stock, without a comparison protocol. (10)
Vekia’s historical engineering effort is substantial enough to assess directly. Its shortcomings lie in the distance between identifiable numerical methods and sweeping product assurances, and in the thin accounting for the labor and costs behind reported benefits.
Numerical decisions and model limits
The current order application considers storage, transport, and ordering costs, with controls for minimum quantities, stock thresholds, replenishment delays, and order frequency. It exposes reasons for proposals and permits manual changes. These are meaningful operational inputs. Their presence does not establish that the combined decision maximizes profit under uncertain demand and supply. (3)
What the published research reveals
The 2024 thesis describes deployed single-item, single-location optimization with sampled demand and piecewise-convex costs, plus a MILP combining precomputed orders across items and periods. Locations remain separate. Its proposed multi-echelon model instead uses mean demand and unlimited, perfectly reliable suppliers. In tests drawn from a 905-item industrial problem, two 40-item subsets hit CPLEX’s two-hour limit. The author develops adaptive local search; simulations improve the stock/shortage balance while increasing total costs, including purchases. Production industrialization and probabilistic demand/supply inputs remain future work at the thesis date. (5, pp. 20–22, 27–30, 40–41, 96–98)
This is a formulation problem as much as a solver problem. Faster search cannot recover uncertainty removed from its inputs. Separating locations also makes local recommendations compete for shared stock after their calculation. A new solver label alone would leave both economic defects intact.
Current probabilistic claims
Vekia now explicitly advertises probabilistic forecasts for demand, delivery times, and stock. Recognizing supplier uncertainty is a substantive strength. Public documentation still supplies no joint calibration results, dependency model, or worked calculation connecting those distributions to competing order choices. (2)
Dependence matters: a promotion can increase demand while congesting replenishment, and one supplier delay can affect many products together. A collection of individually plausible forecasts can therefore understate the chance of a costly combined shortage. The relevant test is whether the resulting decisions remain economically sensible across these outcomes, including cases where normal service targets become too expensive to pursue.
The demand page describes continuously adjusted forecasts and safety stocks, with configurable product and operating contexts. It does not publish a reproducible SKU-level forecast evaluation with horizon, lost-sales treatment, and comparison baseline. Probabilistic terminology is informative, but the quality of the distributions and the value of the actions remain separate empirical questions. (4)
Customer results and economic accountability
Two named cases give the offer a concrete operating context:
| Customer | Published scope and results | What remains unmeasured |
|---|---|---|
| Engie Home Services | A 12-week spare-parts forecast informs replenishment using supplier restrictions, transport costs, and part prices. Vekia reports 10% lower stock value, 5% higher parts availability, and 95% of orders automated. | Measurement period, margin effect, implementation cost, and total continuing labor. (8) |
| Okaidi | The case describes 15–20 million stock positions processed nightly, incorporating product lifecycle, promotions, weather, warehouse conditions, and user parameters. Reported results are 2% less stock and 2% more revenue. | Calculation runtime, comparison design, net profit, and maintenance effort. (9) |
The Okaidi workload is evidence of large-scale processing. A count of stock positions says little about the coupling between decisions: millions of independent calculations and one coordinated network calculation have very different computational demands. Revenue improvement also needs margin and fulfillment costs before it becomes an economic return.
Current functional pages advertise 99% of orders automated and up to 2% additional EBIT, without identifying the cohort, measurement interval, or cost perimeter. The automation percentage concerns orders, not forecasting accuracy. The EBIT statement does not say whether the percentage denotes relative growth or percentage points of revenue. (15)
These gaps leave accountability asymmetric. The vendor publishes attractive benefits while the customer’s parameter choices, data, integrations, and operational execution remain material determinants of performance. No public acceptance method specifies a net-return baseline, attributes deterioration, or commits Vekia to revising the calculation when returns fall short. Economic accountability requires that continuing obligation, not just a successful implementation milestone. (7, 15)
Operating productivity and configuration maintenance
Vekia automates more than report production. Recalculating order proposals and feeding them into an existing system can remove recurring clerical work. The Engie account also describes a central team moving from taking orders to making decisions from the software’s proposals. That is a useful productivity change, although it does not measure the labor left in reviewing those proposals. (8, 17)
The platform itself describes partial automation and one-click validation or adjustment. The relevant denominator is therefore the whole operating workload: routine orders, exceptions, expedites, data repairs, and maintenance. A high share of automatically generated orders can coexist with a costly minority of exceptions. (1)
Configuration adds a second workload. The shortage module allows product-level alert thresholds; the control tower uses events and thresholds set by the customer’s teams. Each setting needs an owner, a reason, and a retirement rule when suppliers, products, or economics change. Otherwise, apparent automation accumulates a hidden manual planning system inside the configuration. (15, 16)
A useful total-cost calculation would include the subscription, integration, hosting-related charges, and the recurring hours spent maintaining those settings. It would also count the delay between discovering a bad recommendation and deploying a tested correction. Vekia’s public offer does not quantify this maintenance workload or describe versioned changes, historical replay, and rollback for the customer’s decision policy. (3, 7)
This is the improvement-productivity question developed in Holimization. Improving the formulation must be cheap enough to do repeatedly. A planner overriding an order fixes today’s transaction; capturing and testing the reason can improve thousands of subsequent decisions.
Software materials and security
Vekia’s November 2025 full-stack posting explicitly lists its application stack. Earlier DevOps recruitment documents the deployment machinery. (6, 14)
| Layer | Published components | Evidence date |
|---|---|---|
| User interface | TypeScript and Angular | November 2025 application posting |
| Backend | Java, Spring, Hibernate, and Scala | November 2025 application posting |
| Data systems | PostgreSQL, MongoDB, and Snowflake | November 2025 application posting |
| Application deployment | Microservices and Azure SaaS | November 2025 application posting |
| Infrastructure and delivery tooling | Linux, Azure, Ansible, Bash, Terraform, Docker, Jenkins, Maven, Nexus, and Kubernetes | February 2021 DevOps posting; current retention of each tool is unspecified |
Three different data platforms impose a real maintenance burden: schema evolution, identity and access controls, backup behavior, synchronization, and incident diagnosis. Their individual roles are not explained publicly. The concern is architectural cost and coordination, especially when one order calculation depends on consistent state across services. Listing fashionable infrastructure does not resolve that burden.
The integration page describes connections to ERP, warehouse, transport, and related systems, with setup duration depending on complexity and the number of systems. Vekia and the customer’s technical team perform that integration together. It supplies no public transaction contract explaining duplicate prevention, rejected-order reconciliation, or which system owns an amended recommendation. Those details determine whether unattended execution remains dependable when a connection fails. (7)
Security disclosure is limited to European Azure hosting, encryption, backups, and general data-protection assurances. Tenant isolation, connector privileges, production-change controls, and tested restoration procedures are not specified. Those are the mechanisms that would limit damage from a compromised account or software dependency. A cloud provider’s reputation cannot substitute for the application’s own design. (2)
Business continuity
The official sequence is clear: safeguard proceedings opened on September 4, 2023; an eight-year safeguard plan was approved on September 4, 2024; that plan was terminated when reorganization proceedings opened on September 28, 2026. The latest notice sets cessation of payments at September 4, 2026. This is reorganization, not a liquidation judgment. (18, 19, 20)
The commercial consequence is a heightened dependency risk. A replenishment service needs more than continued access to a screen: it needs current data pipelines, operational support, maintained algorithms, and recoverable customer configuration. Public integration promises do not establish that the customer can export and operate the configured decision process independently. The software’s technical strengths therefore coexist with an unresolved continuity exposure. (7, 20)
Supply chain score
Supply chain depth
| Criterion | Score |
|---|---|
| Economic framing | 6/10 |
| Decision end-state | 7/10 |
| Conceptual sharpness on supply chain | 6/10 |
| Freedom from obsolete doctrinal centerpieces | 5/10 |
| Robustness against KPI theater | 4/10 |
Average: 5.6/10.
Economic framing — 6/10. Ordering and logistics costs enter the proposition directly. Public explanations leave the reconciliation of these costs with service objectives and uncertain losses incomplete. (3)
Decision end-state — 7/10. The output reaches replenishment quantities and ERP-connected workflows. The remaining weakness is the limited public specification of execution controls and financial acceptance tests. (3, 7)
Conceptual sharpness on supply chain — 6/10. The emphasis on uncertain futures is sound. Selecting a preferred scenario would lose much of that advantage when unlikely outcomes carry disproportionate economic consequences. (10)
Freedom from obsolete doctrinal centerpieces — 5/10. The product reaches beyond deterministic forecasting, but configurable safety levels and alerts still occupy a prominent place. Their economic justification and continuing maintenance remain insufficiently exposed. (4, 16)
Robustness against KPI theater — 4/10. Named cases are more assessable than anonymous benefit claims, but the current EBIT promise and headline improvements lack the definitions needed to calculate net returns. (8, 9, 15)
Decision and optimization substance
| Criterion | Score |
|---|---|
| Probabilistic modeling depth | 5/10 |
| Distinctive optimization or ML substance | 7/10 |
| Real-world constraint handling | 6/10 |
| Decision automation and labor productivity | 6/10 |
| Resilience under real operational complexity | 5/10 |
Average: 5.8/10.
Probabilistic modeling depth — 5/10. Demand and delivery uncertainty are explicitly recognized. The joint distribution, its calibration, and its use in risk-adjusted action selection remain inadequately documented. (2, 4)
Distinctive optimization or ML substance — 7/10. The published algorithms expose substantive development and failed approaches, with a clear gap between research and deployment. (5)
Real-world constraint handling — 6/10. Practical order restrictions and supplier conditions receive direct treatment. Their interactions across locations, competing products, and uncertain supply need fuller documentation. (3, 8)
Decision automation and labor productivity — 6/10. Customer evidence supports removal of repetitive ordering work. Total remaining operating labor, including exceptions and configuration changes, is not measured. (8, 1)
Resilience under real operational complexity — 5/10. The thesis identifies defects in local ordering and develops a broader formulation, with simulated comparisons. Public material provides little detail on deploying such corrections into customer operations and maintaining their regression tests. (5, 16)
Product and architecture integrity
| Criterion | Score |
|---|---|
| Architectural coherence | 5/10 |
| System-boundary clarity | 6/10 |
| Security seriousness | 2/10 |
| Software parsimony and ownership cost | 3/10 |
| Compatibility with programmatic and agent-assisted operations | 5/10 |
Average: 4.2/10.
Architectural coherence — 5/10. A focused replenishment application has a recognizable functional core. The published data stack introduces coordination costs without explaining the responsibilities or consistency boundaries of its separate systems. (1, 6)
System-boundary clarity — 6/10. Vekia positions itself alongside the customer’s transactional software. The division of authority over order changes, retries, and failures remains less clear than the integration diagram. (7, 17)
Security seriousness — 2/10. Hosting, encryption, and backup assurances reveal little about the application’s privilege boundaries, tenant isolation, or ability to recover safely after compromise. (2)
Software parsimony and ownership cost — 3/10. The disclosed application and infrastructure require substantial specialist maintenance. Public material neither explains how overlapping data platforms earn their cost nor measures the customer’s recurring configuration effort. (6, 14, 16)
Compatibility with programmatic and agent-assisted operations — 5/10. ERP integration and automated calculation support programmatic operation. Inspectable interfaces for testing, revising, and safely deploying the customer’s decision policy remain sparse. (7, 17)
Technical transparency
| Criterion | Score |
|---|---|
| Public technical documentation | 7/10 |
| Inspectability without vendor mediation | 5/10 |
| Portability and lock-in visibility | 3/10 |
| Implementation-method transparency | 5/10 |
| Evidence density behind technical claims | 5/10 |
Average: 5.0/10.
Public technical documentation — 7/10. The thesis makes historical numerical methods unusually inspectable; current product documentation is much less precise. (5)
Inspectability without vendor mediation — 5/10. Published features and application components permit meaningful outside assessment. The current end-to-end decision calculation cannot be reproduced from those disclosures. (3, 6)
Portability and lock-in visibility — 3/10. Connecting existing systems reduces replacement work, but exporting data does not transfer the configured models, operating knowledge, or execution process. Their portability remains unspecified. (7)
Implementation-method transparency — 5/10. Integration responsibilities and operational settings are visible. Data validation, model acceptance, configuration migration, and ongoing revision procedures receive much less explanation. (7, 16)
Evidence density behind technical claims — 5/10. Named deployments establish real operating contexts. Reported outcomes omit enough baseline, cost, and labor information to prevent a convincing calculation of attributable economic value. (8, 9)
Vendor seriousness
| Criterion | Score |
|---|---|
| Technical seriousness of public communication | 4/10 |
| Technology roadmap integrity | 4/10 |
| Conceptual sharpness | 6/10 |
| Economic accountability | 3/10 |
| Defensibility in an agentic-software world | 5/10 |
Average: 4.4/10.
Technical seriousness of public communication — 4/10. Concrete probabilistic concepts coexist with claims of unrestricted scale and maximal optimization. Missing evaluation definitions weaken the public communication. (2, 11)
Technology roadmap integrity — 4/10. The long replenishment focus and identifiable product generations support continuity of purpose. Financial reorganization now creates a material risk to sustained engineering and maintenance. (12, 11, 20)
Conceptual sharpness — 6/10. The product addresses inventory economics and repetitive decisions directly. Its explanation of how probable futures become economically preferred actions remains incomplete. (10, 17)
Economic accountability — 3/10. Published benefits are not accompanied by public net-return acceptance criteria or a defined corrective obligation when the decision process underperforms. Continuing configuration responsibilities make that omission consequential. (15, 16)
Defensibility in an agentic-software world — 5/10. Replenishment expertise and automated production workloads retain value. The offer has not demonstrated a comparable reduction in the effort required to diagnose failures and improve the decision process continuously. (9, 1)
Sources
[1] Platform and replenishment workflow
Source. Undated; current page. Accessed November 4, 2026.
[2] Probabilistic technology and hosting
Source. 2025-03-14 (updated). Accessed November 4, 2026.
[3] Order proposals and configurable constraints
Source. Undated; current page. Accessed November 4, 2026.
[4] Demand and stock forecasting
Source. Undated; current page. Accessed November 4, 2026.
[5] Multi-Echelon Inventory Control Optimization Approach for Industrial Applications
Source. 2024-09-20. Accessed November 4, 2026.
[6] Full-stack developer job: production application stack
Source. 2025-11-21. Accessed November 4, 2026.
[7] Integration with transactional systems
Source. Undated; current page. Accessed November 4, 2026.
[8] Engie Home Services replenishment case
Source. 2020-03-28 (updated 2021-03-26). Accessed November 4, 2026.
Source. 2019-01-15 (updated 2020-04-03). Accessed November 4, 2026.
[10] Machine learning and predictive analysis
Source. 2021-05-05. Accessed November 4, 2026.
[11] Company history and April 2021 Engine launch
Source. 2024-10-10 (updated). Accessed November 4, 2026.
[12] Manuel Davy presentation: Internet du futur
Source. 2014-07-03. Accessed November 4, 2026.
[13] Asys acquisition of VekiaPlan
Source. 2016-01-25. Accessed November 4, 2026.
[14] DevOps engineering duties and infrastructure
Source. 2021-02-08 (updated 2021-04-21). Accessed November 4, 2026.
[15] Shortage management and alert thresholds
Source. Undated; current page. Accessed November 4, 2026.
[16] Logistics control tower and configurable alerts
Source. Undated; current page. Accessed November 4, 2026.
[17] Vekia Engine packaged offer
Source. 2021-era page. Accessed November 4, 2026.
[18] BODACC: opening of safeguard proceedings
Source. 2023-09-13. Accessed November 4, 2026.
[19] BODACC: eight-year safeguard plan
Source. 2024-09-13. Accessed November 4, 2026.
[20] BODACC: safeguard plan terminated and reorganization opened
Source. 2026-10-07. Accessed November 4, 2026.