La plupart des configurateurs connus partent d’une variante maximale comme base (« nomenclature maximale, BOM 150 % ») puis filtrent, via un ensemble de règles, jusqu’à une variante concrète. Mais si l’on modélisait plutôt le delta par rapport à une variante de base ?
Si l’on demande aux ingénieurs comment ils décriraient une variante, la réponse arrive bien avant la BOM max achevée, et elle est tout autre : « la machine standard, plus un châssis renforcé et un circuit de refroidissement modifié ». Une base, plus ce qui a changé.
Ce n’est pas ainsi que raisonnent les outils PLM que je connais. Ils construisent le maximum comme modèle de données, et la différence n’apparaît qu’après coup, lorsque ce maximum est filtré par un ensemble de règles jusqu’à une nomenclature à 100 %. Ce n’est pas bloquant en soi — mais chaque traduction du modèle mental (« base plus modification ») vers le modèle de données réel (« maximum moins filtre ») coûte en efficacité et ouvre la porte aux erreurs.
Un modèle inspirant : Delta-Oriented Programming
En développement logiciel, il existe pour cela une approche académique dont on peut s’inspirer : Delta-Oriented Programming. Plutôt que de tout représenter dans une variante maximale, on y trouve une baseline plus des deltas nommés, qui ajoutent, suppriment ou modifient quelque chose. Là aussi, le principe ne s’est jamais généralisé — la plupart des logiciels continuent de fonctionner avec des feature flags. Mais cela permettait de nommer et de versionner la différence, plutôt que de la cacher dans un flag.
Ce que cela pourrait signifier pour l’écosystème d’outils
CONTACT Software, PTC, Siemens Digital Industries Software, Dassault Systèmes, SAP : chacun de ces éditeurs pourrait intégrer la différence comme objet de données à part entière dans la boîte à outils de la configuration produit — en alternative pour tous les cas où les ingénieurs pensent déjà en deltas. Les modèles de features et les BOM max continueraient de faire leur travail pour le reste.
L’argumentation détaillée — avec la méthode en détail et la question des limites du transfert du logiciel vers le hardware — se trouve dans mon article sur variantmanagement.com.
La plupart des méthodes de configuration modélisent le maximum et n’en déduisent la différence qu’après coup. Delta-Oriented Programming montre une alternative : la différence elle-même devient un objet de données nommé et versionné. Ce n’est pas un remplacement pour les modèles de features et les BOM max — mais un outil supplémentaire pour tous les cas où les ingénieurs pensent déjà en deltas.
