Retour aux Études de marché
Vekia est une application cloud de prévision de la demande, de gestion des stocks et de réapprovisionnement. Elle calcule des propositions de commande, identifie les risques de pénurie, surveille les flux logistiques et relie ces fonctions aux systèmes transactionnels existants des clients. Ses applications comprennent le réapprovisionnement du commerce et la fourniture de pièces de rechange. (1, 7, 8)
Note globale de supply chain : 5,0/10.
| Dimension | Note |
|---|---|
| Profondeur en supply chain | 5,6/10 |
| Substance des décisions et de l’optimisation | 5,8/10 |
| Intégrité du produit et de l’architecture | 4,2/10 |
| Transparence technique | 5,0/10 |
| Sérieux de l’éditeur | 4,4/10 |
Vekia traite des décisions concrètes de commande et reconnaît explicitement l’incertitude de la demande et des délais de livraison. Ses cas clients rapportent une automatisation substantielle. La question technique non résolue est l’étendue de la prise en compte de ces incertitudes dans le calcul économique entre produits et sites. La recherche publique révèle des formulations plus restrictives que la promesse actuelle d’optimisation maximale pour toute supply chain ou tout volume de données. (2, 8, 5)
La continuité d’activité est aussi une préoccupation immédiate. Le 28 septembre 2026, le tribunal de commerce de Lille Métropole a résolu le plan de sauvegarde de Vekia et ouvert un redressement judiciaire. La période d’observation court jusqu’au 28 mars 2027. Pour un service calculant des décisions récurrentes de réapprovisionnement, la continuité de l’hébergement, du support et de la maintenance des modèles doit entrer dans la décision d’achat aux côtés de la performance numérique. (20)
Vekia face à Lokad
Les deux éditeurs visent à remplacer les calculs répétitifs de réapprovisionnement par du logiciel. Vekia fournit une application standard : prévisions, paramètres de stock, propositions priorisées et écrans de revue. Son offre Engine présente aussi la prévision et l’automatisation des commandes comme un complément à l’ERP existant. (1, 17)
L’optimisation des stocks de Lokad se concentre sur un modèle numérique maintenu des décisions du client. Incertitudes de demande et d’approvisionnement, conséquences économiques et restrictions opérationnelles entrent dans ce modèle ; les Supply Chain Scientists développent et maintiennent le calcul. La sortie visée est un ensemble d’actions classées économiquement, avec un effort humain concentré sur l’amélioration du processus décisionnel. C’est la perspective de conception plus large développée dans Introduction to Supply Chain.
La différence pratique concerne ce qui se passe lorsqu’une recommandation est erronée. Un système standard peut inviter à une dérogation, un changement de seuil ou un autre paramètre fournisseur. Un modèle de décision maintenu devrait transformer l’échec en calcul révisé et retester ses effets sur l’ensemble de l’activité. Vekia expose des fonctions de configuration et d’explication, mais peu de détails publics sur cette seconde boucle. Sa valeur dépend donc en partie de la correction récurrente restant à la charge du client. (3, 15)
Historique technologique et concrétisation
La trajectoire de Vekia couvre plus d’une décennie de prévision et de réapprovisionnement. Son histoire situe le début de l’activité en 2008, le passage du conseil au logiciel en 2010 et la transition SaaS en 2018. Le positionnement initial sur l’IA concernait la prédiction numérique et les commandes, bien avant la génération actuelle d’agents à modèles de langage. (11)
| Période | Éléments publics | Portée |
|---|---|---|
| 2014 | La présentation de Manuel Davy à l’Université de Lille décrit des décisions quotidiennes de stock, des ventes rares par produit et magasin, des capacités logistiques et une fenêtre de calcul de quelques heures. | Le problème initial était opérationnellement précis. (12) |
| 2016 | Asys acquiert VekiaPlan et son équipe de planification du personnel. | Il s’agissait du produit de planification des effectifs, pas du rachat de l’activité de réapprovisionnement de Vekia. (13) |
| 2019–2021 | Les cas publiés Okaidi et Engie décrivent des charges de réapprovisionnement et des résultats rapportés. | Ils établissent des déploiements derrière le récit du machine learning. (9, 8) |
| 2021 | Engine démarre avec prévision probabiliste, intégration ERP et amélioration revendiquée de 25% sur la génération précédente. | L’amélioration n’a ni métrique ni protocole de test publié. (11) |
| 2024 | Une thèse soutenue par Vekia étudie le réapprovisionnement multi-échelons. | Elle expose algorithmes, hypothèses restrictives et travaux d’industrialisation non résolus. (5) |
| 2025–2026 | Les pages actuelles insistent sur l’IA probabiliste et un APS extensible ; l’offre d’emploi applicative nomme trois plateformes de données. | La promesse élargie exige une description correspondante du périmètre numérique et du coût d’infrastructure. (2, 6) |
L’article de machine learning de 2021 illustre l’écart entre une idée utile et une explication excessive. Il s’éloigne à raison de la prédiction d’un seul futur certain, mais décrit ensuite la sélection du scénario le plus probable et de celui qui correspond aux objectifs métier. La question décisive reste sans réponse : les actions sont-elles valorisées sur tous les résultats possibles, y compris des échecs coûteux peu probables, ou choisies face à un futur préféré ? Le même article rapporte une expérience promotionnelle anonyme avec 26% de chiffre d’affaires supplémentaire et 42% de stock résiduel en moins, sans protocole de comparaison. (10)
L’effort d’ingénierie historique de Vekia est assez substantiel pour être évalué directement. Ses insuffisances résident dans l’écart entre méthodes numériques identifiables et assurances générales sur le produit, ainsi que dans le faible décompte du travail et des coûts derrière les bénéfices annoncés.
Décisions numériques et limites du modèle
L’application actuelle de commandes considère coûts de stockage, transport et passation, avec des contrôles sur quantités minimales, seuils de stock, délais de réapprovisionnement et fréquence des commandes. Elle expose les raisons des propositions et permet des changements manuels. Ce sont des entrées opérationnelles significatives. Leur présence n’établit pas que la décision combinée maximise le profit sous demande et approvisionnement incertains. (3)
Ce que révèle la recherche publiée
La thèse de 2024 décrit une optimisation déployée par article et site, avec demande échantillonnée et coûts convexes par morceaux, puis un MILP combinant des commandes précalculées entre articles et périodes. Les sites restent séparés. Le modèle multi-échelons proposé utilise au contraire une demande moyenne et des fournisseurs illimités, parfaitement fiables. Dans des tests tirés d’un problème industriel de 905 articles, deux sous-ensembles de 40 articles atteignent la limite de deux heures de CPLEX. L’auteur développe une recherche locale adaptative ; les simulations améliorent l’équilibre stock-pénurie tout en augmentant les coûts totaux, achats compris. L’industrialisation en production et les entrées probabilistes de demande et d’approvisionnement restent des travaux futurs à la date de la thèse. (5, p. 20–22, 27–30, 40–41, 96–98)
C’est autant un problème de formulation que de solveur. Une recherche plus rapide ne récupère pas l’incertitude retirée des entrées. Séparer les sites fait aussi concourir les recommandations locales pour un stock commun après leur calcul. Une nouvelle étiquette de solveur laisserait intactes ces deux défaillances économiques.
Promesses probabilistes actuelles
Vekia annonce désormais explicitement des prévisions probabilistes de demande, de délais de livraison et de stock. Reconnaître l’incertitude fournisseur est une force substantielle. La documentation publique ne fournit toujours ni calibration conjointe, ni modèle de dépendances, ni calcul détaillé reliant ces distributions à des choix concurrents de commande. (2)
La dépendance compte : une promotion peut accroître la demande et congestionner le réapprovisionnement, tandis qu’un retard fournisseur peut toucher plusieurs produits simultanément. Des prévisions individuellement plausibles peuvent donc sous-estimer la probabilité d’une pénurie combinée coûteuse. Le test pertinent est de savoir si les décisions restent économiquement sensées sur ces résultats, y compris lorsque poursuivre les objectifs habituels de service devient trop coûteux.
La page de demande décrit des prévisions et stocks de sécurité continuellement ajustés, avec des contextes produit et opérationnels configurables. Elle ne publie pas d’évaluation reproductible des prévisions au niveau SKU avec horizon, traitement des ventes perdues et référence comparative. La terminologie probabiliste est informative, mais qualité des distributions et valeur des actions restent deux questions empiriques distinctes. (4)
Résultats clients et responsabilité économique
Deux cas nommés donnent un contexte opérationnel concret à l’offre :
| Client | Périmètre et résultats publiés | Ce qui reste non mesuré |
|---|---|---|
| Engie Home Services | Une prévision de pièces à 12 semaines éclaire le réapprovisionnement avec restrictions fournisseurs, coûts de transport et prix des pièces. Vekia rapporte 10% de valeur de stock en moins, 5% de disponibilité supplémentaire et 95% de commandes automatisées. | Période de mesure, effet sur la marge, coût d’implémentation et travail continu total. (8) |
| Okaidi | Le cas décrit 15–20 millions de positions de stock traitées chaque nuit, en intégrant cycle de vie produit, promotions, météo, conditions d’entrepôt et paramètres utilisateurs. Les résultats annoncés sont 2% de stock en moins et 2% de chiffre d’affaires en plus. | Temps de calcul, protocole comparatif, profit net et effort de maintenance. (9) |
La charge Okaidi prouve un traitement à grande échelle. Le nombre de positions de stock dit peu du couplage des décisions : des millions de calculs indépendants et un calcul coordonné de réseau ont des exigences très différentes. Une hausse de chiffre d’affaires a aussi besoin des marges et coûts d’exécution pour devenir un rendement économique.
Les pages fonctionnelles actuelles annoncent 99% de commandes automatisées et jusqu’à 2% d’EBIT supplémentaire, sans identifier cohorte, période de mesure ou périmètre des coûts. Le pourcentage d’automatisation concerne les commandes, pas la précision des prévisions. La promesse d’EBIT ne précise pas s’il s’agit d’une croissance relative ou de points de chiffre d’affaires. (15)
Ces lacunes rendent la responsabilité asymétrique. L’éditeur publie des bénéfices attractifs tandis que paramètres, données, intégrations et exécution du client restent des déterminants importants de la performance. Aucune méthode publique d’acceptation ne spécifie une référence de rendement net, n’attribue une dégradation ou n’engage Vekia à revoir le calcul si les rendements déçoivent. La responsabilité économique nécessite cette obligation continue, pas seulement un jalon d’implémentation réussi. (7, 15)
Productivité opérationnelle et maintenance de configuration
Vekia automatise davantage que la production de rapports. Recalculer les propositions de commande et les transmettre au système existant peut supprimer du travail administratif récurrent. Le récit Engie décrit aussi une équipe centrale passant de la prise de commandes à des décisions sur les propositions du logiciel. C’est un changement utile de productivité, sans mesure du travail restant pour revoir ces propositions. (8, 17)
La plateforme décrit elle-même une automatisation partielle et une validation ou correction en un clic. Le dénominateur pertinent est donc toute la charge opérationnelle : commandes ordinaires, exceptions, accélérations de livraison, réparations de données et maintenance. Une forte proportion de commandes générées automatiquement peut coexister avec une minorité coûteuse d’exceptions. (1)
La configuration ajoute une seconde charge. Le module de pénurie permet des seuils d’alerte par produit ; la tour de contrôle utilise événements et seuils définis par les équipes clientes. Chaque paramètre a besoin d’un responsable, d’une raison et d’une règle de retrait lorsque fournisseurs, produits ou économie changent. Sinon, l’automatisation apparente accumule un système manuel de planification caché dans la configuration. (15, 16)
Un calcul utile de coût total inclurait abonnement, intégration, frais liés à l’hébergement et heures récurrentes de maintenance des paramètres. Il compterait aussi le délai entre la découverte d’une mauvaise recommandation et le déploiement d’une correction testée. L’offre publique de Vekia ne quantifie pas cette maintenance et ne décrit ni changements versionnés, ni rejeu historique, ni retour arrière de la politique de décision du client. (3, 7)
C’est la question de productivité d’amélioration développée dans Holimization. Améliorer la formulation doit être assez peu coûteux pour être répété. Un planificateur corrigeant une commande répare la transaction du jour ; saisir et tester la raison peut améliorer des milliers de décisions ultérieures.
Composants logiciels et sécurité
L’offre d’emploi full-stack de Vekia de novembre 2025 énumère explicitement les technologies de l’application. Un recrutement DevOps antérieur documente les outils de déploiement. (6, 14)
| Couche | Composants publiés | Date du document |
|---|---|---|
| Interface utilisateur | TypeScript et Angular | Offre applicative de novembre 2025 |
| Backend | Java, Spring, Hibernate et Scala | Offre applicative de novembre 2025 |
| Systèmes de données | PostgreSQL, MongoDB et Snowflake | Offre applicative de novembre 2025 |
| Déploiement applicatif | Microservices et Azure SaaS | Offre applicative de novembre 2025 |
| Infrastructure et livraison | Linux, Azure, Ansible, Bash, Terraform, Docker, Jenkins, Maven, Nexus et Kubernetes | Offre DevOps de février 2021 ; maintien actuel de chaque outil non précisé |
Trois plateformes de données distinctes imposent une véritable charge : évolution des schémas, identités et droits, sauvegardes, synchronisation et diagnostic d’incidents. Leurs rôles individuels ne sont pas expliqués publiquement. La préoccupation est le coût architectural et la coordination, notamment lorsqu’un calcul de commande dépend d’un état cohérent entre services. Énumérer une infrastructure à la mode ne résout pas cette charge.
La page d’intégration décrit les connexions aux ERP, systèmes d’entrepôt, transport et systèmes connexes, avec une durée de configuration dépendant de la complexité et du nombre de systèmes. Vekia et l’équipe technique du client réalisent ensemble l’intégration. Elle ne donne pas de contrat transactionnel public expliquant prévention des doublons, rapprochement des commandes rejetées ou système responsable d’une recommandation modifiée. Ces détails déterminent si l’exécution sans intervention reste fiable lors d’une défaillance de connexion. (7)
La divulgation de sécurité se limite à l’hébergement Azure européen, au chiffrement, aux sauvegardes et à des assurances générales de protection des données. Isolation des clients, privilèges des connecteurs, contrôles de modification en production et procédures de restauration testées ne sont pas précisés. Ces mécanismes limiteraient les dommages d’un compte ou d’une dépendance compromis. La réputation du fournisseur cloud ne remplace pas la conception propre de l’application. (2)
Continuité d’activité
La séquence officielle est claire : ouverture d’une sauvegarde le 4 septembre 2023 ; adoption d’un plan de huit ans le 4 septembre 2024 ; résolution de ce plan lors de l’ouverture du redressement judiciaire le 28 septembre 2026. Le dernier avis fixe la cessation des paiements au 4 septembre 2026. Il s’agit d’un redressement, pas d’un jugement de liquidation. (18, 19, 20)
La conséquence commerciale est un risque accru de dépendance. Un service de réapprovisionnement exige davantage que l’accès continu à un écran : pipelines de données à jour, support opérationnel, algorithmes maintenus et configuration client récupérable. Les promesses publiques d’intégration n’établissent pas que le client puisse exporter et exploiter indépendamment le processus configuré. Les forces techniques coexistent donc avec un risque de continuité non résolu. (7, 20)
Note de supply chain
Profondeur en supply chain
| Critère | Note |
|---|---|
| Cadre économique | 6/10 |
| Aboutissement concret des décisions | 7/10 |
| Netteté conceptuelle sur la supply chain | 6/10 |
| Affranchissement des doctrines obsolètes | 5/10 |
| Résistance au théâtre des KPI | 4/10 |
Moyenne : 5,6/10.
Cadre économique — 6/10. Les coûts de commande et de logistique entrent directement dans la proposition. Les explications publiques laissent incomplète leur réconciliation avec objectifs de service et pertes incertaines. (3)
Aboutissement concret des décisions — 7/10. La sortie atteint les quantités de réapprovisionnement et des processus connectés à l’ERP. La faiblesse restante est la spécification publique limitée des contrôles d’exécution et des tests d’acceptation financière. (3, 7)
Netteté conceptuelle sur la supply chain — 6/10. L’accent sur des futurs incertains est juste. Choisir un scénario préféré perdrait une grande partie de cet avantage lorsque des résultats improbables ont des conséquences économiques disproportionnées. (10)
Affranchissement des doctrines obsolètes — 5/10. Le produit dépasse la prévision déterministe, mais les niveaux de sécurité et alertes configurables restent importants. Leur justification économique et leur maintenance continue sont insuffisamment exposées. (4, 16)
Résistance au théâtre des KPI — 4/10. Les cas nommés sont plus évaluables que des bénéfices anonymes, mais la promesse actuelle d’EBIT et les gains mis en avant manquent de définitions nécessaires au calcul de rendements nets. (8, 9, 15)
Substance des décisions et de l’optimisation
| Critère | Note |
|---|---|
| Profondeur de la modélisation probabiliste | 5/10 |
| Substance distinctive de l’optimisation ou du ML | 7/10 |
| Traitement des contraintes réelles | 6/10 |
| Automatisation des décisions et productivité du travail | 6/10 |
| Résilience face à la complexité opérationnelle réelle | 5/10 |
Moyenne : 5,8/10.
Profondeur de la modélisation probabiliste — 5/10. Les incertitudes de demande et de livraison sont reconnues explicitement. La distribution conjointe, sa calibration et son usage dans la sélection d’actions ajustées au risque restent insuffisamment documentés. (2, 4)
Substance distinctive de l’optimisation ou du ML — 7/10. Les algorithmes publiés exposent un développement substantiel et des approches infructueuses, avec un écart clair entre recherche et déploiement. (5)
Traitement des contraintes réelles — 6/10. Restrictions pratiques de commande et conditions fournisseurs sont directement traitées. Leurs interactions entre sites, produits concurrents et approvisionnement incertain nécessitent davantage de documentation. (3, 8)
Automatisation des décisions et productivité du travail — 6/10. Les preuves clients soutiennent la suppression de travail répétitif de commande. Le travail opérationnel restant, exceptions et changements de configuration compris, n’est pas mesuré dans son ensemble. (8, 1)
Résilience face à la complexité opérationnelle réelle — 5/10. La thèse identifie des défauts de commandes locales et développe une formulation élargie, avec comparaisons simulées. Peu de détails publics portent sur le déploiement de ces corrections chez les clients et la maintenance des tests de régression. (5, 16)
Intégrité du produit et de l’architecture
| Critère | Note |
|---|---|
| Cohérence architecturale | 5/10 |
| Clarté des frontières du système | 6/10 |
| Sérieux en matière de sécurité | 2/10 |
| Parcimonie logicielle et coût de possession | 3/10 |
| Compatibilité avec des opérations programmatiques et assistées par agents | 5/10 |
Moyenne : 4,2/10.
Cohérence architecturale — 5/10. Une application ciblée sur le réapprovisionnement a un cœur fonctionnel reconnaissable. Les technologies de données publiées ajoutent des coûts de coordination sans expliquer les responsabilités ou frontières de cohérence des systèmes séparés. (1, 6)
Clarté des frontières du système — 6/10. Vekia se positionne à côté du logiciel transactionnel du client. L’autorité sur les changements de commande, nouvelles tentatives et échecs reste moins claire que le schéma d’intégration. (7, 17)
Sérieux en matière de sécurité — 2/10. Les assurances d’hébergement, chiffrement et sauvegarde révèlent peu des frontières de privilèges, de l’isolation des clients ou du rétablissement sûr après compromission. (2)
Parcimonie logicielle et coût de possession — 3/10. L’application et l’infrastructure divulguées demandent une maintenance spécialisée importante. Les documents publics n’expliquent ni comment des plateformes de données qui se recoupent justifient leur coût, ni l’effort récurrent de configuration du client. (6, 14, 16)
Compatibilité avec des opérations programmatiques et assistées par agents — 5/10. Intégration ERP et calcul automatisé permettent un fonctionnement programmatique. Les interfaces inspectables pour tester, revoir et déployer sûrement la politique de décision du client restent rares. (7, 17)
Transparence technique
| Critère | Note |
|---|---|
| Documentation technique publique | 7/10 |
| Inspectabilité sans médiation de l’éditeur | 5/10 |
| Portabilité et visibilité du verrouillage | 3/10 |
| Transparence de la méthode d’implémentation | 5/10 |
| Densité des preuves derrière les affirmations techniques | 5/10 |
Moyenne : 5,0/10.
Documentation technique publique — 7/10. La thèse rend les méthodes numériques historiques inhabituellement inspectables ; la documentation produit actuelle est beaucoup moins précise. (5)
Inspectabilité sans médiation de l’éditeur — 5/10. Fonctions et composants publiés permettent une évaluation externe significative. Le calcul actuel de bout en bout ne peut être reproduit à partir de ces divulgations. (3, 6)
Portabilité et visibilité du verrouillage — 3/10. Connecter les systèmes existants réduit le remplacement, mais exporter des données ne transfère ni modèles configurés, ni savoir opérationnel, ni processus d’exécution. Leur portabilité reste non précisée. (7)
Transparence de la méthode d’implémentation — 5/10. Responsabilités d’intégration et paramètres opérationnels sont visibles. Validation des données, acceptation du modèle, migration de configuration et révisions continues reçoivent beaucoup moins d’explications. (7, 16)
Densité des preuves derrière les affirmations techniques — 5/10. Les déploiements nommés établissent des contextes réels. Les résultats omettent assez d’informations sur références, coûts et travail pour empêcher un calcul convaincant de valeur économique attribuable. (8, 9)
Sérieux de l’éditeur
| Critère | Note |
|---|---|
| Sérieux technique de la communication publique | 4/10 |
| Intégrité de la feuille de route technologique | 4/10 |
| Netteté conceptuelle | 6/10 |
| Responsabilité économique | 3/10 |
| Défendabilité dans un monde de logiciels agentiques | 5/10 |
Moyenne : 4,4/10.
Sérieux technique de la communication publique — 4/10. Des concepts probabilistes concrets coexistent avec des promesses d’échelle illimitée et d’optimisation maximale. L’absence de définitions d’évaluation affaiblit la communication. (2, 11)
Intégrité de la feuille de route technologique — 4/10. Le long ancrage dans le réapprovisionnement et les générations identifiables soutiennent une continuité de finalité. Le redressement financier crée désormais un risque substantiel pour une ingénierie et une maintenance durables. (12, 11, 20)
Netteté conceptuelle — 6/10. Le produit traite directement l’économie des stocks et les décisions répétitives. L’explication de la transformation des futurs probables en actions économiquement préférables reste incomplète. (10, 17)
Responsabilité économique — 3/10. Les bénéfices publiés ne s’accompagnent pas de critères publics d’acceptation du rendement net ni d’une obligation définie de correction lorsque le processus déçoit. Les responsabilités permanentes de configuration rendent cette omission importante. (15, 16)
Défendabilité dans un monde de logiciels agentiques — 5/10. L’expertise de réapprovisionnement et les charges de production automatisées conservent leur valeur. L’offre n’a pas démontré une réduction comparable de l’effort de diagnostic des échecs et d’amélioration continue du processus. (9, 1)
Sources
[1] Plateforme et processus de réapprovisionnement
Source. Non datée ; page actuelle. Consultée le 4 novembre 2026.
[2] Technologie probabiliste et hébergement
Source. 2025-03-14 (mise à jour). Consultée le 4 novembre 2026.
[3] Propositions de commande et contraintes configurables
Source. Non datée ; page actuelle. Consultée le 4 novembre 2026.
[4] Prévision de la demande et du stock
Source. Non datée ; page actuelle. Consultée le 4 novembre 2026.
[5] Approche d’optimisation du contrôle des stocks multi-échelons pour applications industrielles
Source. 2024-09-20. Consultée le 4 novembre 2026.
[6] Poste de développeur full-stack : technologies de l’application en production
Source. 2025-11-21. Consultée le 4 novembre 2026.
[7] Intégration avec les systèmes transactionnels
Source. Non datée ; page actuelle. Consultée le 4 novembre 2026.
[8] Cas de réapprovisionnement Engie Home Services
Source. 2020-03-28 (mise à jour 2021-03-26). Consultée le 4 novembre 2026.
[9] Cas de réapprovisionnement Okaidi
Source. 2019-01-15 (mise à jour 2020-04-03). Consultée le 4 novembre 2026.
[10] Machine learning et analyse prédictive
Source. 2021-05-05. Consultée le 4 novembre 2026.
[11] Histoire de l’entreprise et lancement d’Engine en avril 2021
Source. 2024-10-10 (mise à jour). Consultée le 4 novembre 2026.
[12] Présentation de Manuel Davy : Internet du futur
Source. 2014-07-03. Consultée le 4 novembre 2026.
[13] Acquisition de VekiaPlan par Asys
Source. 2016-01-25. Consultée le 4 novembre 2026.
[14] Responsabilités d’ingénierie DevOps et infrastructure
Source. 2021-02-08 (mise à jour 2021-04-21). Consultée le 4 novembre 2026.
[15] Gestion de la pénurie et seuils d’alerte
Source. Non datée ; page actuelle. Consultée le 4 novembre 2026.
[16] Tour de contrôle logistique et alertes configurables
Source. Non datée ; page actuelle. Consultée le 4 novembre 2026.
[17] Offre standard Vekia Engine
Source. Page de l’époque 2021. Consultée le 4 novembre 2026.
[18] BODACC : ouverture de la sauvegarde
Source. 2023-09-13. Consultée le 4 novembre 2026.
[19] BODACC : plan de sauvegarde de huit ans
Source. 2024-09-13. Consultée le 4 novembre 2026.
[20] BODACC : résolution du plan de sauvegarde et ouverture du redressement
Source. 2026-10-07. Consultée le 4 novembre 2026.