Logiciel de gestion de stock avec IA en 2026 : la cartographie

Si vous avez parcouru les grilles G2 ou Capterra pour « logiciel de gestion de stock IA », vous voyez le problème. La promesse implicite, c'est que tous ces éditeurs sont substituables.

RELEX, Blue Yonder, SAP IBP, ToolsGroup, o9, Manhattan, Oracle Retail, Increff, Autone, Nextail — auxquels s'ajoutent une longue traîne d'éditeurs WMS et leur module de forecasting récent. Une enseigne qui lit la grille en conclurait raisonnablement que le choix se joue sur le prix, les partenaires d'intégration et deux ou trois cases à cocher.

Ce cadrage est faux, et il coûte cher. Les éditeurs de cette grille ont été construits pour des problèmes structurellement différents. Un produit conçu pour tenir un état de stock exact ne coordonnera jamais les flux de décision comme un produit construit autour d'un graphe de décision. Un produit conçu pour gagner les benchmarks de précision continuera de traiter allocation, réappro, transfert et démarque comme des optimisations séparées. La donnée a beau dire qu'elles partagent le même état, l'architecture ne le voit pas.

La catégorie que vous choisissez fixe le plafond de valeur que vous pouvez extraire, indépendamment de l'éditeur précis avec lequel vous signez.

Cet article re-bucketise le paysage 2026 sur ce pour quoi chaque archétype a été construit. Ensuite, sept critères d'évaluation qui prédisent la valeur à 18 mois mieux qu'une liste de fonctionnalités, et une lecture franche de l'anatomie tarifaire.

La catégorie que personne n'a bucketisée proprement

Trois archétypes coexistent sur le marché aujourd'hui. Ils paraissent adjacents sur une grille de fonctionnalités et se comportent comme des espèces différentes en production.

Archétype 1 — système de référence avec IA en surcouche

C'est de loin la base installée la plus large. WMS, OMS et modules de stock adjacents à l'ERP, avec une capacité de forecasting greffée dans les dernières versions. Pensez Manhattan Active, SAP IBP, Oracle Retail Merchandise, les modules stock des ERP mid-market. À cela s'ajoute la longue traîne d'éditeurs WMS qui ont licencié un moteur de prévision et réécrit le marketing.

Ce pour quoi ils sont construits. Tenir un état transactionnel exact du stock à travers le parc. Réception, picking, expédition, retours, comptages, réconciliation financière. Le métier du système de référence est réel et ils le font bien — la plupart ont été affinés vingt ans contre ce problème précis.

Où se trouve l'IA. En module. Un forecast tourne la nuit, une proposition de réappro est générée, un acheteur revoit et valide. Allocation, transfert et démarque vivent dans des modules adjacents qui consomment le même forecast, mais prennent leurs décisions en silo. Il n'y a pas d'état décisionnel partagé entre eux — chaque module possède sa tranche et écrit dans le système de référence indépendamment.

Force. La profondeur d'intégration côté exécution est imbattable. Le modèle de données parle déjà WMS, les écritures financières sont propres, la DSI connaît l'éditeur. L'adoption opérationnelle sur la couche d'exécution est un non-sujet : les opérateurs sont déjà dans l'outil.

Faiblesse. La coordination inter-décisions est structurellement impossible.

Une montée de demande en région A déclenche le module de réappro qui commande davantage d'entrant. L'allocation répartit en magasin avec la courbe de l'an dernier. La démarque sur le résidu de la saison précédente poursuit son calendrier sans rien voir. Chaque décision est localement raisonnable.

La somme, c'est le constat de chaque enseigne — « le bon produit est dans le mauvais magasin ». Aucune précision de modèle dans un module ne le réduit.

Archétype 2 — spécialistes du forecasting

Le cluster auquel pense la plupart des acheteurs retail en entendant « logiciel de gestion de stock IA ». RELEX, ToolsGroup, Blue Yonder demand, certaines briques d'o9, plus une cohorte française et nordique comme Vekia ou Optilon. La filiation est celle de l'optimisation supply chain académique — demand sensing, forecast probabiliste, modèles de stock de sécurité, mathématiques multi-échelons. Solide, défendable, et très visible en appel d'offres.

Ce pour quoi ils sont construits. Réduire l'erreur de forecast et utiliser cette réduction pour calibrer de meilleures quantités de réappro. Le produit d'origine était un moteur de prévision ; le module de réappro est venu ensuite ; allocation et démarque ont été ajoutées au fil des demandes clients.

Où se trouve l'IA. Au cœur du forecasting et du réappro, avec des modules adjacents pour allocation, transfert, démarque et assortiment. Ces modules partagent typiquement le signal de demande, mais pas l'état de décision. Chacun résout une optimisation sous contrainte localement et écrit dans le système. Quand deux modules sont en désaccord, le conflit se règle par ordre de configuration ou par un humain en réunion.

Force. La précision de forecast et la profondeur du réappro. Si votre mix catégoriel se joue sur la qualité du forecast (grande distribution mature, FMCG, réappro à haute fréquence), cet archétype a l'outillage le plus poussé. Les déploiements de référence sont nombreux et les métriques bien instrumentées.

Faiblesse. Chaque décision vit dans son module. L'allocation ne sait pas ce que fait la démarque ; le transfert ignore la vague de réappro suivante ; l'assortiment tourne sur un autre horizon de planification. Le résultat : une pile de modules localement optimisés au comportement global diffus — et un long projet d'intégration coûteux pour les faire coexister sur votre donnée. Le time-to-first-decision en production tourne typiquement entre 9 et 18 mois, parfois plus, parce que l'onboarding de chaque module est son propre sous-projet.

Archétype 3 — plateformes décisionnelles

L'archétype le plus récent, et la base installée la plus petite. La liste est courte :

• Solya
• Certaines briques d'o9 (cadrage decision-cloud plutôt que planning-suite)
• Quelques builds sur mesure sur dbt + Snowflake + une couche d'orchestration
• Quelques entrants européens positionnés explicitement sur le décisioning

Ce pour quoi ils sont construits. Coordonner plusieurs décisions de stock — allocation, réappro, transfert, démarque, assortiment — sur un état de décision partagé. Le forecast est une entrée parmi d'autres, pas le centre de l'architecture.

Le système est conçu autour d'un graphe de décision. Chaque nœud est une décision, chaque arête encode l'état partagé, et la couche d'orchestration garde le graphe cohérent à mesure que la donnée bouge.

Où se trouve l'IA. À l'intérieur du graphe de décision, pas dans des modules. Un forecast nourrit l'allocation. Le résultat de l'allocation contraint le réappro. Les résultats de réappro nourrissent le modèle de démarque, et les décisions de démarque mettent à jour l'assortiment de la saison suivante.

Le même état est lu et écrit par chaque décision — c'est ce qui rend la coordination inter-décisions possible.

Force. Cohérence inter-décisions et time-to-first-decision. Parce que l'architecture est decision-first plutôt que module-first, le premier périmètre peut être en production en 90-120 jours sur un périmètre réaliste. Une catégorie, une région, la boucle de décision complète câblée bout en bout. Une fois la boucle vivante, ajouter des catégories devient une affaire d'onboarding de donnée, pas de reconstruction de l'architecture.

Faiblesse. Catégorie récente, moins de précédents dans la liste de références, peu d'histoires de type « on a déployé ça à 600 magasins il y a dix ans ». Le risque plus profond : une couche de décision ne vaut que par son accès aux systèmes opérationnels en dessous. Si le write-back vers votre WMS ou ERP est fragile, le graphe produit de beaux plans qui n'atteignent jamais le terrain. Les bons éditeurs de cet archétype investissent lourdement dans la surface d'intégration pour cette raison précise.

Sept critères qui prédisent le ROI à 18 mois

Les listes de fonctionnalités ne prédisent pas la valeur. Ce qui la prédit, assez fiablement, c'est la réponse à sept questions que vous pouvez poser en démo et vérifier en pilote.

Un — état de décision partagé. La plateforme peut-elle faire tourner allocation, réappro, transfert et démarque sur le même état sous-jacent ? Si l'allocation et le réappro ne voient pas ce que la démarque a fait, vous avez un stack forecasting avec un problème de coordination — absorbé en opérations.

Deux — write-back, pas dashboard. La décision se propage-t-elle vers les systèmes d'exécution — WMS, ERP, OMS, moteur de pricing, e-commerce — ou s'arrête-t-elle à un tableau de bord ou à un fichier d'export ? Une décision qui n'atteint pas le système de référence est, opérationnellement, une slide. C'est là que beaucoup de revendications d'éditeur sur « l'intégration SAP » méritent une question de suivi sur lecture ou écriture.

Trois — correction sans casser le modèle. Un acheteur peut-il corriger une décision unique (une référence, un magasin, une semaine) sans invalider l'apprentissage du modèle ni forcer un réentraînement ? Si le seul chemin de correction est « coupez la règle », les opérateurs la coupent et ne la rallument jamais. La correction doit être un signal de première classe que le système absorbe.

Quatre — support multi-échelon. La plateforme raisonne-t-elle sur DC → magasin → référence comme un graphe connecté, ou optimise-t-elle chaque niveau localement ? Un outil qui ignore cette structure laisse une part mesurable de marge sur la table, en transferts et en équilibrage de stock.

Cinq — SLA de fraîcheur de décision. Quelle cadence la plateforme s'engage-t-elle à tenir — et quelle cadence son architecture sait réellement soutenir ? Un batch hebdomadaire convient pour la planification d'assortiment ; il est trop lent pour une catégorie frais ou pour le demand sensing sur une ligne à forte rotation. Demandez la cadence par type de décision, pas un chiffre unique.

Six — surface d'intégration, lecture ET écriture. Combien de vos systèmes opérationnels la plateforme peut-elle lire et écrire dès le premier jour ? Lister des connecteurs est facile ; la vraie question, c'est lesquels portent du trafic production chez les clients de référence, pas lesquels existent dans la documentation. Si le write-back est une ligne de prestation hors SOW, vous le découvrirez au mois neuf.

Sept — time-to-first-decision en production. Pas « time-to-first-dashboard », pas « précision du modèle acceptable », mais le temps avant la première décision exécutée dans votre système réel, sur un périmètre réel. Pour les plateformes décisionnelles, 90-120 jours est réaliste sur un périmètre ciblé. Pour les stacks forecasting-first où chaque module est son propre projet d'intégration, 9-18 mois est plus typique. Pour le système de référence avec IA en surcouche, le module de forecast peut sortir plus vite, mais chaque problème de coordination inter-décisions retombe ensuite sur vous.

Notez les plateformes de votre évaluation sur ces sept critères, pondérés pour votre contexte, et la réponse aura l'air très différente d'un classement par grille de fonctionnalités.

L'objection « on a déjà un WMS »

C'est le pushback le plus fréquent quand on discute de plateforme décisionnelle avec une DSI. « On a passé six ans et beaucoup d'argent sur le rollout WMS. On ne va pas acheter un autre système de stock. »

C'est la bonne objection à soulever et la mauvaise conclusion à en tirer. Un WMS et une couche de décision résolvent des problèmes différents. Le WMS vous dit où est le stock maintenant — par référence, par lot, par emplacement, avec l'intégrité transactionnelle nécessaire pour piloter picking et expédition. Une couche de décision vous dit où le stock devrait être la semaine prochaine, compte tenu de la demande, de l'horloge de démarque et des contraintes réseau. Question différente, modèle de données différent, cadence différente.

Le schéma de coexistence est bien établi. Le WMS reste le système de référence pour l'état du stock et le système d'exécution pour les opérations entrepôt. La couche de décision lit cet état en continu, fait tourner le graphe, et écrit les actions recommandées — réappro, transferts, allocation, démarque — via les API standard du WMS.

Le WMS gère l'exécution ; la couche de décision gère la coordination. Aucun ne remplace l'autre.

Le même schéma vaut pour l'ERP et l'OMS. Aucun de ces systèmes n'a été conçu pour coordonner allocation, réappro et démarque comme un graphe cohérent. C'est un travail de couche décisionnelle par architecture, pas une fonctionnalité qu'un système d'exécution finira par livrer. Les enseignes qui évitent cette confusion traitent les couches comme des compléments à frontières propres, pas comme des concurrents qui se disputent la même charge.

Anatomie tarifaire

Le pricing de cette catégorie est opaque par choix, mais les drivers de coût ne sont pas mystérieux. Trois variables expliquent l'essentiel de la variance.

Périmètre de décisions. Une plateforme configurée pour ne piloter que le réappro est matériellement moins chère qu'une plateforme qui fait tourner la boucle complète allocation + réappro + transfert + démarque. Les éditeurs facturent par modules, par périmètre ou par hybride ; plus vous allumez de types de décision, plus le plancher monte.

Taille et complexité du parc. Nombre de références, de magasins, de DC, et de chaînes d'approvisionnement distinctes composent l'équation de licence. Une enseigne régionale de 50 magasins sur une seule chaîne ne paie pas comme un groupe international de 600 magasins avec trois DC régionaux et un stack e-commerce. La plupart des éditeurs indexent sur au moins une de ces variables.

Périmètre d'intégration. C'est la ligne la plus sous-estimée dans les budgets initiaux. Chaque système opérationnel qui demande une intégration lecture/écriture ajoute du temps de prestation. Sur une stack legacy hétérogène, ce chiffre peut rivaliser avec la licence en année un.

Pour fixer des ordres de grandeur, sans nommer d'éditeur. Un premier déploiement ciblé sur une décision et une catégorie atterrit typiquement en bas de six chiffres annuels pour la plateforme seule, avec une prestation comparable en année un. Un rollout multi-décisions sur une enseigne nationale tourne en milieu de six à sept chiffres annuels selon l'échelle. Ce sont des fourchettes, pas des devis ; vos chiffres réels dépendent de l'archétype, des décisions allumées, et de la propreté de votre donnée.

Le chiffre à suivre n'est pas la licence isolée. C'est le coût total jusqu'à la première décision exécutée — licence, prestations, travail interne sur la donnée, et coût des mois entre signature et valeur. Sur cette métrique, l'écart d'archétype est décisif. Une plateforme décisionnelle qui atteint la première décision en 120 jours coûte mesurablement moins, sur ces quatre mois, qu'un stack forecasting-first qui passe 14 mois en intégration avant de livrer.

Solya dans le paysage

Solya est decision-layer-first par conception. L'architecture est construite autour d'un graphe de décision avec un modèle d'état partagé. Voir la couche d'orchestration pour la façon dont cet état coordonne allocation, réappro, transfert et démarque. Voir aussi la couche intelligence pour la façon dont les décisions sortent du signal unifié. Le forecast est une entrée qui alimente le graphe ; il n'est pas le centre de l'architecture.

Le compromis est honnête. Solya est faite pour les enseignes qui ont conclu que leur goulot est la coordination inter-décisions, pas la précision de forecast. Si votre problème est réellement un problème de forecast — disons, sans vraie couche de demand sensing — un spécialiste forecasting-first peut convenir. Si vous avez déjà des forecasts, un WMS, un outil de planification, mais que les décisions ne sont toujours pas d'accord — c'est le gap qu'une couche de décision adresse.

La question à poser avant la prochaine démo

Emportez une seule question dans votre prochain rendez-vous éditeur. Quel état partagé la plateforme tient-elle entre allocation, réappro, transfert et démarque — et comment puis-je le voir à l'écran ? Un éditeur dont l'architecture est module-first vous donnera une réponse soignée sur l'intégration API et la configuration. Un éditeur dont l'architecture est decision-first vous montrera le modèle d'état à l'écran et déroulera un flux concret inter-décisions.

Aucune des deux réponses n'est juste ou fausse dans l'absolu. Elles vous disent à quel archétype vous parlez — et quel plafond de valeur arrive avec. Lisez le reste de la cartographie, le guide d'achat pour le scoring des capacités, le cadrage build vs buy pour l'alternative, et le guide RFP pour structurer l'évaluation. Votre short-list aura alors l'air très différente de la grille G2.

---

Vous évaluez un logiciel de gestion de stock IA pour 2026 ?

Nous proposons aux directions retail et supply chain un diagnostic de cartographie de 30 minutes. L'objectif : situer votre short-list face aux trois archétypes, la noter sur les sept critères, et faire émerger quelle architecture correspond au goulot que vous cherchez vraiment à résoudre.

Vous repartez avec :

• Une lecture par catégorie de votre short-list — dans quel archétype chaque éditeur se situe, et pourquoi
• Les deux ou trois critères d'évaluation les plus susceptibles d'être décisifs pour votre parc et votre mix catégoriel
• Une estimation réaliste de time-to-first-decision pour chaque architecture face à votre donnée et vos systèmes