Quels sont les critères pour développer des nouvelles fonctions transversales à vos progiciels de gestion ?Tous les outils que nous commercialisons sont cohérents sur les plans fonctionnel et technique. Si l’on essaie de greffer un outil généraliste d’aide à la décision ou de workflow sur nos produits, cela ne marche généralement pas : certains de nos clients sont tentés par une telle approche, mais ils l’abandonnent souvent. En effet, sur notre marché, la notion de retour sur investissement est très présente. Et, avec les outils généralistes, le prix à payer est trop lourd. Par exemple, si l’on avait juxtaposé un progiciel du marché à notre PGI pour intégrer des fonctions de GED (gestion électronique de documents ?” NDLR), les clients n’auraient utilisé que 20 à 30 % de ses fonctions. D’un autre côté, le développement d’un tel outil en interne ne se révèle pas forcément pertinent sur les plans stratégique ou financier. Il nous faut donc travailler très étroitement avec les éditeurs pour adapter leurs produits aux besoins de nos clients.La taille de votre entreprise est relativement modeste. Quelle est votre marge de man?”uvre avec d’éventuels partenaires technologiques ?Elle n’est pas énorme. Si les éditeurs ont une politique commerciale dure ou fluctuante, nous sommes pris en tenaille. Et nous ne pouvons pas nous le permettre : la maintenance et l’évolution de nos produits représentent déjà 80 % de notre activité. Le choix du partenaire s’effectue en fonction de la cohérence commerciale et de la dépendance induite. Et, évidemment, de l’adéquation de l’outil. Nous n’avons pas un poids suffisant pour imposer nos vues aux grands éditeurs américains. Et je ne peux pas demander à quelqu’un qui commercialise un outil à 100 000 francs de me faire une offre à 15 000 ou 30 000 francs. Dans ce cas, nous préférons développer tout ou partie de la fonctionnalité en interne. Et la technologie entre ainsi chez le client. C’est le cas, par exemple, du module décisionnel, que nous avons vendu à près de deux cents exemplaires en un an et demi.Votre module décisionnel est un patchwork de développement interne et de briques technologiques du marché. Comment s’est opérée sa genèse ?Par rapport aux outils décisionnels proposés sur le marché, nous avons détecté trois niveaux de restitution. Le premier concerne les transactions prévues au niveau des éditions, c’est-à-dire la gestion des états et le reporting. Notre valeur ajoutée réside dans le calcul et la mise en forme de la donnée. Il ne s’agit que d’un traitement séquentiel basique. Le deuxième niveau se rapporte à l’analyse des données de façon plus libre que ce qui est prévu par l’applicatif. C’est la restitution d’états. On se rapproche alors plus du décisionnel. C’est le premier point d’entrée des outils d’aide à la décision. Mais, dans notre cas, il y aurait sous-utilisation du produit générique : nos bases de données opérationnelles sont déjà organisées de manière que le temps de réponse soit optimisé. Pour cela, nous avons dû les “dérégulariser”. Ce qui pose des problèmes pour attaquer nos données en frontal. Nous ne voulons pas réinventer Business Objects (BO) ou Cognos. Mais il n’est pas question non plus de transformer nos clients en informaticiens. Avec les adaptations que nous proposons, nous pouvons répondre à plus de 90 % des besoins. Le troisième niveau a trait à l’interface. Nous utilisons BO et Cognos. Ce sont tous deux de très bons outils. Nous avons créé une couche en amont pour encapsuler les univers, cubes et autres modèles de représentation des données. Grâce à ce traitement, BO et Cognos deviennent des outils de navigation. Les logiciels décisionnels sont des moyens d’atteindre un objectif, et non un but en soi. On ne propose pas de la technologie pour la technologie.Vous annoncez votre volonté de progresser sur l’intégration de vos produits dans des systèmes d’information hétérogènes. N’est-ce pas un peu tard ?Du point de vue de l’intégration fonctionnelle ?” connecteurs et encapsulation ?”, nous sommes au point. Etant à l’origine éditeur de logiciels spécialisés, nous avons très tôt dû nous intégrer dans n’importe quel système d’information. Nous voulons surtout progresser dans le domaine de l’EAI (intégration d’application d’entreprise ?” NDLR) technique, c’est-à-dire la mise en relation des objets de nature différente. Les produits des éditeurs généralistes du secteur ne nous conviennent pas. Ce qui ne nous empêche pas, en revanche, d’être aussi en étroite relation avec IBM autour de Websphere. Enfin, nous sommes en train de développer un moteur 100 % Java, qui devrait nous permettre de devenir véritablement multi-plate-forme.En travaillant sur un moteur Java, ne cédez-vous justement pas à une mode technologique ?Java est le langage rêvé pour un éditeur fonctionnel. Il va nous permettre d’ouvrir plus facilement nos produits. Et il est économique en matière de service rendu par rapport à l’investissement. De plus, nos spécialistes Java ont de l’expérience. Ils savent ce que développer et maintenir un produit veut dire. Parce que si ce langage est très structurant et qu’il a une forte capacité d’abstraction, il nécessite de bien préparer les choses en amont. Si l’on ne surveille pas le processus de développement, cela peut se révéler impossible à maintenir.Vos clients ne sont-ils pas attirés par la technologie ?Ils sont surtout pragmatiques, parfois rétrogrades. Mais c’est essentiellement pour des questions budgétaires. La communication des éditeurs se fait de plus en plus sur les moyens, et non sur les objectifs, alors que notre cible achète de la fonctionnalité. Si l’on peut améliorer le produit et le rendre disponible avec de la technologie, pourquoi pas ? Le problème de l’entreprise est surtout de ne pas se planter. Nous faisons de l’informatique d’objectif. Nous ne sommes pas une société de services. Si nous instaurons une politique de R&D aspirée par la technologie, le marché aura vite fait de nous recadrer.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
