Comment un planificateur supply chain a construit un moteur IBP avec Claude en 80 heures

L’Integrated Business Planning a longtemps rimé avec licences à six chiffres et déploiements de deux ans. Un praticien chez TELUS prouve que la discipline compte plus que la plateforme.

La plupart des équipes supply chain parlent d’Integrated Business Planning. Très peu le construisent réellement. La raison est simple. La méthodologie est solide, mais les outils sont soit trop chers, soit trop rigides. Pour les petites et moyennes entreprises, l’écart entre la théorie de la planification et son exécution reste béant depuis des décennies.

C’est cet écart qu’Alain Matar a décidé de combler. Senior IBP Leader chez TELUS, Matar a présenté un moteur IBP fonctionnel qu’il a construit avec Claude lors de la première GSCC Builder Session, un nouveau format où les praticiens montrent ce qu’ils ont construit plutôt que de parler d’IA dans l’abstrait. Le résultat n’était pas une démo commerciale. C’était un véritable outil, utilisé pour piloter une activité de distribution alimentaire et de confiserie dans huit pays du Moyen-Orient.

Le problème du téléphone arabe

Matar a passé plus de 20 ans dans le supply chain à travers quatre univers très différents. Il a commencé dans la logistique des opérations de maintien de la paix de l’ONU, où une rupture de stock n’est pas un échec de service mais une crise. De là, il est passé par le retail, la pharma, le gaz, et aujourd’hui les télécoms. Le fil conducteur était partout le même. La planification vivait ou mourait selon les personnes présentes dans la pièce, pas selon le logiciel.

Il a décrit les deux voies traditionnelles qui s’offrent aux entreprises. Vous achetez une plateforme d’entreprise et acceptez ses hypothèses sur votre activité, puis vous adaptez vos opérations à l’outil. Ou vous embauchez un développeur, vous lui expliquez votre métier, et vous le regardez construire quelque chose qui capte environ la moitié de ce que vous avez dit. Vous corrigez. Il reconstruit. Vous recommencez la boucle jusqu’à épuisement du budget. Les entreprises appellent cela de l’itération. Matar appelle cela le téléphone arabe.

Son moteur supprime entièrement la couche de traduction. Il a architecturé la solution et écrit le code lui-même sur quelques week-ends. Aucun développeur au milieu. “C’est juste moi et Claude”, a-t-il dit. Il donne ses instructions en langage clair et Claude exécute. Ce qui change tout, selon lui, c’est que la personne qui comprend le métier peut désormais construire l’outil, et que l’outil peut évoluer aussi vite que l’entreprise.

Ce que fait réellement le moteur

La version qu’il a présentée était la version 11. Elle tourne dans le navigateur et couvre l’ensemble du cycle de planification Oliver Wight Class A, soit environ 26 étapes.

Le panneau d’administration attribue des rôles aux demand planners, supply planners, inventory planners, commercial managers, contrôleurs financiers, acheteurs, responsables de magasin et dirigeants. Chaque rôle reçoit un périmètre défini par branche. Cette structure a résolu le problème central de l’entreprise. Avant, 20 planificateurs travaillaient à partir de 20 fichiers Excel, sans séparation des responsabilités ni source unique de chiffres. Quand un planificateur partait, le fichier partait avec lui.

Le moteur fonctionne par gestion des exceptions. Avec des milliers de références sur de nombreuses branches, personne ne peut suivre chaque signal de demande. Le système signale donc les anomalies. Une référence qui se vend à 10 unités par mois et qui grimpe soudain à 40 est remontée automatiquement. Comme l’a résumé Matar, les exceptions représentent 20% des problèmes mais 80% de la valeur.

Le volet demande inclut un tracker de lancement de nouveaux produits, un calendrier de cadeaux calé sur le Ramadan, l’Aïd, le Nouvel An chinois et Noël, des modèles de prévision statistique, une segmentation ABC-XYZ et par durée de conservation, et du demand sensing sur des fenêtres de 4, 13 et 26 semaines. Le volet approvisionnement gère l’intelligence sur les matières premières, connectée par API à la plateforme d’achat du client, le réapprovisionnement premier expiré premier sorti, la capacité usine par ligne et la couverture en matières premières. La réconciliation intégrée rassemble le tout avec analyse des écarts, allocation par canal et réconciliation financière. Un pack de revue mensuelle se génère automatiquement et part vers les VP chaque quatrième semaine.

Coût, sécurité et le revers de la médaille

L’économie du projet est frappante. Matar a démarré avec Claude Pro à environ 20 dollars par mois, puis est passé au forfait Max à environ 100 dollars. Il estime que la version 11 a demandé environ 80 heures, facilitées par le fait que les moteurs précédents lui offraient une base à personnaliser.

Il a appris l’hébergement cloud et la sécurité de zéro. Claude l’a guidé étape par étape pour déployer sur Google Cloud avec authentification unique et Firestore. Il a utilisé les 400 dollars de crédits gratuits de Google Cloud pour tester d’abord.

Il a été direct sur les risques. Vous devez auditer et stress tester le code. Il a passé 250 scénarios de test pour valider la logique. Son avertissement le plus tranchant portait sur le modèle lui-même. “Le problème avec Claude, c’est qu’il est trop intelligent”, a-t-il dit. Il fait des erreurs, puis vous convainc que ces erreurs sont correctes. C’est précisément pourquoi les plans de test sont essentiels.

Interrogé sur la question de savoir si cela remplace Kinaxis, SAP ou Blue Yonder, sa réponse était claire. Si vous avez un budget de plusieurs millions de dollars et 12 à 24 mois, ces plateformes sont la bonne réponse. Elles sont puissantes, matures et éprouvées. Son outil occupe un autre espace. Il s’adresse aux petites et moyennes entreprises qui ont besoin de la discipline IBP mais ne peuvent justifier la licence et l’implémentation. Fait notable, il a souligné que Kinaxis s’est déjà associé à un cabinet boutique pour viser ce même marché, signe que la tendance est réelle.

Sa prochaine cible est de remplacer PowerBI et Tableau par une couche visuelle complète. Il diversifie aussi son workflow avec Codex en secours, basculant entre les modèles quand l’un atteint une limite.

Enseignements pour les dirigeants supply chain

La discipline est l’actif, pas le tableau de bord. Matar a martelé que l’outil compte parce qu’il construit la discipline IBP, le fondement même du processus. Les graphiques et les scores de maturité sont secondaires.

Commencez petit et itérez vite. Les imports manuels, les rapports d’exception et une source unique de vérité délivrent de la valeur avant toute intégration ERP profonde. L’avantage de construire soi-même, c’est que l’itération est rapide et immédiate.

L’expertise métier est la vraie barrière à l’entrée. Vous n’avez pas besoin d’être développeur. Vous avez besoin de comprendre le supply chain et la méthodologie Oliver Wight assez bien pour savoir quand la logique est cassée. L’IA gère le code. Vous gérez le jugement.

Un planificateur normal pourrait-il construire quelque chose de ce genre ? Et si la réponse est oui, qu’est-ce que cela signifie pour les prochains contrats de logiciels d’entreprise que votre société va signer ?

Partagez votre avis en commentaire. Si vous souhaitez voir le moteur en action, vous pouvez demander une démo directement à Alain à l’adresse Mattaralain@gmail.com. Alain est également membre de Chain.NET et vous pouvez le contacter sur https://www.chain.net/u/a141ce1b.

Le replay complet de cette Builder Session est disponible pour les membres payants du GSCC sur Chain.NET à l’adresse https://www.chain.net/c/session-replays/.

Poursuivez la discussion sur Chain.NET, la communauté mondiale du supply chain, sur www.chain.net. Posez vos questions, participez à la prochaine Builder Session et accédez à des ressources exclusives.