La préparation à l’IA commence par des données produit fiables

Les fabricants investissent massivement dans l’IA, les initiatives de continuité numérique, l’automatisation et la modernisation de l’entreprise afin d’améliorer la productivité et la prise de décision. Une grande partie des discussions porte sur les modèles d’IA, les infrastructures et l’intégration. Pourtant, de nombreuses organisations négligent un prérequis fondamental à ces efforts : la confiance dans les données produit sous-jacentes et les règles métier qui orientent les décisions opérationnelles.

Le défi ne consiste pas simplement à connecter les systèmes, mais à veiller à ce que les définitions des produits, la logique de configuration et les règles métier qui circulent entre eux restent exactes. La préparation à l’IA commence par la confiance dans les données produit de l’entreprise. La transformation numérique ne consiste pas seulement à connecter des systèmes ; elle vise aussi à préserver le sens et l’exactitude des informations qui circulent entre eux.

À mesure que les entreprises modernisent leurs systèmes et connectent la gestion du cycle de vie des produits (PLM), la planification des ressources de l’entreprise (ERP), les plateformes de configuration, de tarification et de devis (CPQ) et les plateformes de service, les incohérences dans la logique de configuration peuvent discrètement compromettre l’exactitude des processus en aval et l’efficacité des recommandations fondées sur l’IA. Sans logique de configuration fiable, l’IA accélère les erreurs au lieu d’améliorer les décisions.

Pourquoi la configuration des produits est le fondement méconnu

Les fabricants d’aujourd’hui s’appuient de plus en plus sur un écosystème interconnecté qui englobe le PLM, l’ERP, le CPQ, la fabrication et le service. La configuration des produits sert de tissu conjonctif : elle traduit les intentions de l’ingénierie en exigences de fabrication, de vente, de tarification et de service.

Chaque système a une vision différente du produit : le PLM a besoin des informations techniques et de conception, la fabrication doit savoir ce qui peut être produit, et le CPQ doit connaître les règles de vente et de marché. La configuration relie ces perspectives. Lorsque la logique sous-jacente change ou devient incohérente, le fil numérique se rompt, quelle que soit la qualité de l’intégration des systèmes.

Les règles héritées introduisent des risques invisibles

Les modèles de configuration des produits représentent souvent des décennies de connaissances accumulées et stratifiées au fil du temps : exigences réglementaires, contraintes de fabrication, exceptions propres à certains marchés et logique de tarification. Les personnes qui ont initialement créé ces modèles ont souvent quitté l’entreprise, laissant les organisations avec des règles que plus personne ne comprend pleinement.

Les projets de modernisation de l’entreprise, comme les migrations vers SAP S/4HANA, mettent généralement l’accent sur les applications, l’infrastructure et le code personnalisé, tandis que la logique de configuration est reléguée au second plan. Il en résulte un risque négligé : les systèmes peuvent être migrés avec succès, alors même que leur comportement en matière de configuration change subtilement, d’une manière difficile à détecter au moyen des tests traditionnels.

Les migrations vers S/4HANA illustrent bien le problème : un nouveau moteur de configuration peut interpréter différemment des règles établies de longue date, malgré une syntaxe identique. Des différences dans l’application des valeurs par défaut, l’ordre d’évaluation des contraintes et la résolution des conflits entre règles peuvent modifier les combinaisons acceptées par un modèle, sans qu’une seule ligne des règles elles-mêmes ait été réécrite.

Il ne s’agit pas seulement d’une source de confusion : une logique de configuration défaillante devient un problème commercial. Il existe deux modes de défaillance, et tous deux coûtent cher :

• Une configuration permet à une entreprise de vendre quelque chose qu’elle ne peut en réalité pas fabriquer, ce qui entraîne des reprises, des engagements non tenus et une détérioration des relations avec les clients.
• Une configuration empêche à tort une entreprise de vendre quelque chose qu’elle pourrait fabriquer, ce qui entraîne une perte de revenus et peut-être aussi un recul de son avantage concurrentiel.

Le premier mode de défaillance finit par se manifester dans l’atelier. Le second passe inaperçu : rien dans le carnet de commandes ne fait état d’une vente que le configurateur n’a jamais autorisée.

La vérification devient une capacité stratégique

La validation traditionnelle des migrations repose largement sur des tests manuels et des contrôles ponctuels, qui ne peuvent pas évaluer de manière réaliste l’immense nombre de combinaisons de produits possibles. La vérification de la configuration déplace l’attention : il ne s’agit plus de savoir si les données ont été transférées correctement, mais si l’intention métier a été préservée.

J’ai vu des fabricants affecter des équipes dont la seule mission est de confirmer qu’un modèle migré produit toujours les mêmes configurations valides et rejette toujours les mêmes configurations non valides, simplement parce qu’ils n’ont aucun autre moyen de le savoir. C’est un travail minutieux, coûteux et chronophage qui, même ainsi, ne porte que sur un échantillon du problème.

Il convient d’être précis sur l’ampleur du problème. Un modèle comportant 30 variables et cinq choix pour chacune permet environ 10²¹ combinaisons, soit bien plus que le nombre estimé de grains de sable sur Terre, et les modèles industriels réels sont considérablement plus grands. Même en multipliant les personnes qui parcourent une interface utilisateur, il est impossible de couvrir un tel espace : les calculs ne le permettent pas.

C’est pourquoi les méthodes formelles sont importantes. Plutôt que d’échantillonner des combinaisons, un modèle de configuration peut être compilé sous une forme logique canonique : une représentation mathématique compacte de chaque combinaison valide autorisée par ses règles. Deux modèles compilés de cette manière peuvent être comparés directement. Soit ils décrivent exactement le même ensemble de produits valides, soit la comparaison indique précisément où ils divergent, avec des exemples concrets de combinaisons que l’un accepte et que l’autre rejette. Cette même représentation transforme le comportement à l’exécution en consultation plutôt qu’en recherche, ce qui permet à un configurateur de n’afficher que des options valides et de ne jamais conduire l’utilisateur dans une impasse. La vérification et la correction à l’exécution s’avèrent être une seule et même capacité envisagée sous deux angles différents.

Les organisations ont de plus en plus besoin de ce type de comparaison formelle avant de superposer de l’IA ou de l’automatisation à leurs règles produit. L’objectif ne consiste pas seulement à réduire les risques liés à la migration, mais aussi à préserver la continuité opérationnelle dans les domaines de l’ingénierie, de la fabrication, des ventes et du service, et à pouvoir tester, déboguer et vérifier les modèles de configuration avant leur mise en production plutôt qu’après.

L’IA doit s’appuyer sur un moteur déterministe, et non le remplacer

Rien de tout cela n’exige que l’IA remplace le moteur de configuration. Le modèle le plus pérenne est à l’inverse le suivant : l’IA s’interpose entre l’utilisateur et un moteur de configuration rigoureux, offrant une expérience de vente guidée ou de recommandation plus naturelle, tandis que les règles sous-jacentes restent déterministes. Le modèle de langage interprète la demande du client ; le moteur détermine ce qui peut réellement être fabriqué. Cette répartition des tâches évite de confier à un système probabiliste par conception la partie du processus dont la correction doit pouvoir être démontrée.

La réussite des programmes d’IA repose sur la fiabilité des données

L’IA ne peut générer des recommandations fiables que dans la mesure où les connaissances sur les produits qu’elle reçoit le sont. Des données de configuration non vérifiées amènent l’IA à propager des erreurs à l’échelle de l’entreprise, ce qui compromet les conseils de vente, les décisions de fabrication et les engagements pris envers les clients.

Les fabricants devraient considérer la vérification des données comme un préalable au déploiement de l’IA, au même titre que les tests logiciels sont devenus indispensables au développement d’applications. À mesure que la transformation numérique se poursuit, l’avantage concurrentiel viendra de plus en plus non pas du fait de déployer l’IA en premier, mais de le faire sur des bases constituées de connaissances fiables sur les produits.