Middleware RFID : comment réussir son choix ?

Dans ce domaine, on rencontre aussi bien de petits éditeurs spécialisés (GlobeRanger, ConnecTerra, OATSystems) que des grands noms du logiciel (IBM, Sun, Oracle, Sybase, et bientôt Microsoft). Il faut y ajouter les fabricants de lecteurs (Symbol, Intermec, Coronis.), sans oublier les leaders de la SCE (Manhattan, RedPrairie) et de l'ERP (SAP).

Comment alors faire son marché en assurant la pérennité la plus complète à la solution que l'on retiendra finalement ? Dire qu'il suffit de choisir un produit qui a fait ses preuves et qui respecte les standards du marché est certes le point de départ d'une recherche de solution, mais ce n'est nullement le point d'arrivée ! En effet, d'autres facteurs doivent être pris en compte. Examinons donc les principales étapes de cette « quête du Graal » Richesse fonctionnelle contre surface financière Certains prétendent qu'il faut toujours attacher ses wagons à une locomotive. Une telle approche est généralement payante sur le long terme lorsqu'il s'agit de produits génériques ne demandant pas d'ajustement particulier à l'environnement de l'entreprise. Or, la diversité du commerce aidant, il est difficile de généraliser en matière de middleware RFID. Certes, il n'y a aucun risque à adopter la solution d'un grand éditeur, si ce n'est celui de faire avec ce que fait tout le monde, c'est-à-dire la même chose. Si toutefois, on désire bénéficier d'un avantage concurrentiel, il sera peut-être préférable de tourner son regard vers les solutions des éditeurs de plus petite taille, mais considérés comme pionniers dans le Magic Quadrant du Gartner Group. Même en pareil cas, il est facile de ne pas se tromper. Un simple coup d'oeil sur les alliances conclues par ces sociétés avec de grands éditeurs permet de distinguer rapidement celles susceptibles d'être acquises par un grand nom, garantie de leur survie dans un milieu ô combien changeant. Ne surtout pas à raisonner en termes de coût d'acquisition Il est vrai que la RFID coûte cher, non seulement au niveau de l'infrastructure matérielle, mais aussi à celui de l'infrastructure logicielle. Pour éviter les déconvenues et notamment les abandons purs et simples de pilotes du fait d'une croissance exponentielle des dépenses mal maîtrisées, il est bon de raisonner sur son middleware non uniquement en termes de fonctionnalités mais également en termes d'enveloppe d'investissement. En premier lieu, il ne faut pas réinventer la roue. Autrement dit, si l'on dispose déjà d'un middleware pour gérer les données en provenance des codes-barres, il n'est guère besoin que d'acquérir les modules complémentaires proposés par le même éditeur pour gérer cette fois-ci les flux de données RFID. On doit toutefois mettre un bémol à pareille affirmation. Si la RFID est pensée en termes de refonte complète des processus, il sera bon de se demander si une simple rustine sur l'ancien système suffira ou s'il n'est pas préférable d'adopter une nouvelle solution. En tout état de cause, un élément devra impérativement être conservé en l'état : la base de données de l'entreprise ou plus exactement les bases de données métier. À ce stade, ce n'est pas tant le coût du logiciel qui devrait être pris en compte, que les dépenses induites pour l'intégrer dans le système d'information, pour former le personnel à son maniement, et surtout pour le faire évoluer sur une période moyenne de trois à cinq ans. Choisir un système ouvert Désormais, il est difficile de raisonner en termes de systèmes propriétaires. C'est pourquoi il est préférable de privilégier un middleware intégrant au minimum le standard EPC et au mieux les autres standards, notamment asiatiques. Tout dépend, bien évidemment, des contrées avec lesquelles on commerce. Par ailleurs, la base même du middleware a fortement intérêt à être développée soit sous Java soit sous Windows. De plus, si l'essentiel des serveurs de l'entreprise tourne sous Linux, il sera préférable d'adopter un middleware utilisant le même système d'exploitation. Enfin, c'est l'ouverture au niveau des lecteurs et au niveau des bases de données qui fera toute la différence. Dans ce cadre, on privilégiera un logiciel capable de filtrer les données du plus grand nombre de périphériques RFID possible (voire une solution dont l'injecteur est déjà intégré sur certains matériels, ce qui fera gagner du temps de traitement), un logiciel également capable de router les données traitées dans le plus grand nombre possible de bases de données (car raisonner simplement au niveau de la seule base de données de l'entreprise, c'est oublier un peu vite que la RFID est appelée à sortir rapidement des boucles fermées pour s'étendre à des boucles ouvertes intégrant fournisseurs et clients dont les bases de données ne sont pas forcément toutes sous Oracle !).