A quand des logiciels d’entreprise génériques?

L’un des gros problèmes de l’informatique d’entreprise à l’heure actuelle est son coût. Les projets d’ERP (Enterprise Resource Planning) et de CRM (Customer Relationship Management) sont connus pour être très longs et très coûteux à mettre en œuvre. La raison tient en un mot: la personnalisation. Customiser une solution de CRM pour qu’elle s’accommode au fonctionnement de l’entreprise n’est pas une mince affaire, et la route est semée d’embuches.

Tout d’abord, les personnalisations peuvent être complexes – un exemple typique est le nombre d’exceptions aux règles (suivant un type de client, service ou produit particulier). Parfois même, les customisations doivent être redéveloppées de A à Z. Voici un scénario trop commun: l’équipe de développement propose un cahier des charges sur ce que la customisation doit faire. Mais les managers qui prennent les décisions étant des gens très occupés, ils assistent rarement aux réunions avec le développement et lisent rarement les mémos. Le développement ayant une échéance, ils assument que le cahier des charges convient à tout le monde et commencent à coder. Jusqu’au jour où un manager prend finalement le temps de lire ledit cahier des charges (souvent après que le développement soit terminé) et s’aperçoit que le résultat est inaplicable à l’entreprise. Oups!

Finalement, la customisation d’une solution de CRM empêche souvent la mise à jour vers des versions les plus récentes dudit CRM. Nombreuses sont les entreprises qui utilisent des versions périmées car bloquées par leurs personnalisations.

La solution serait bien évidemment de ne rien personnaliser et d’utiliser son ERP ou CRM tel quel. De fait, tout le monde critique la personnalisation à outrance. Mais dans les faits personne ne veut lâcher ses propres customisations, citant des besoins spécifiques à son organisation.

Mais dans l’histoire de l’informatique on trouve certains types de logiciels génériques (« prêt-à-porter ») qui ont remplacé les logiciels « sur mesure ». Des logiciels où la personnalisation ne demande pas (ou peu) de programmation.

Le tableur: programme de compatibilité générique

Lorsque le tableur a été inventé, les premiers comptables qui l’ont vu en bavaient d’envie. Et pour cause: cela leur permettait de faire leur travail beaucoup plus facilement.

Avant le tableur, seules les grosses entreprises pouvaient informatiser leur comptabilité. Il fallait en effet se payer les services d’un (de plusieurs) informaticien(s) qui devai(en)t programmer à la main le logiciel de compta en incorporant toutes les subtilités spécifiques à la compagnie.

Le tableur a littéralement révolutionné (et je n’emploie pas ce terme à la légère) l’informatique car il a permit à n’importe quel comptable de se « programmer » son propre logiciel de compta en n’ayant à entrer que des formules. Certes, les premiers tableurs n’offraient pas toutes les fonctionnalités offertes par des logiciels créés sur mesure. Mais c’était suffisant pour les petites entreprises. Et avec le temps, le tableur s’est amélioré, a offert plus de fonctionnalités, s’est doté d’un langage de macros[-commandes] et a pu couvrir les besoins de plus en plus complexes.

Le navigateur Web: client générique

Le terme « client/serveur » a été un terme à la mode pendant longtemps en informatique d’entreprise. On installe un logiciel sur les postes clients qui va se connecter à un serveur.

Dans cette architecture, le développement de l’interface graphique (ou GUI, pour Graphical User Interface) était tout sauf standardisé. Car la manière de développer une interface graphique changeait selon le système d’exploitation, le langage de développement utilisé ainsi que le fournisseur du compilateur. Vous vouliez développer un GUI en C++ sous Windows? Les MFC (Microsoft Foundation Classes) de Microsoft et l’OWL (Object Windows Library) de Borland offraient deux manières différentes. Vous vouliez développer un GUI sous Windows en utilisant une solution Microsoft? Visual C++ et Visual Basic offraient une manière de développer l’interface graphique totalement différente.

Le navigateur Web a, lui, apporté un client générique. La clé à été le HTML qui s’est avéré être un puissant langage de description d’interface graphique quelle que soit la plate-forme. Le HTML étant simple, il pouvait être généré par n’importe quel langage de programmation ou n’importe quel logiciel sur n’importe quelle plate-forme.

Là encore, les premiers navigateurs avaient des capacités limitées. Il a fallu 10 ans pour qu’ils de développer un GUI qui rivalise un tant soi peu avec le client/serveur traditionnel. Qui plus est, avec le HTML on ne peut pas calibrer l’interface graphique au pixel près. Mais qu’importe! Le navigateur a permit de développer facilement une interface graphique avec qui plus est un déploiement immédiat. Et au fil des versions, le standard HTML s’est amélioré, s’est doté d’un langage de script (JavaScript) et a pu couvrir des besoins de plus en plus complexes.

L’utilité d’un langage métier

Ces deux exemples mettent en avant l’utilisation d’un « langage métier » (business language). Par langage métier j’entend un langage qui n’est pas destiné aux informaticiens mais aux utilisateurs. Le tableur ne parle pas en terme de variables mais en terme de colonnes, formules et pourcentages. Le HTML ne parle pas en terme de bitmap, widget ou windows handle mais en terme de pagination, de style de texte ou de tableau.

Le HTML est en plus un langage fortement intelligent dans la mesure où beaucoup des choix sont implicites, évitant à l’utilisateur de spécifier toutes les options de pagination possibles. Si par exemple on définit un tableau dont la largeur prenne 75% de la page, le navigateur Web va s’assurer que le tableau ait la bonne dimension quelle que soit la taille de la fenêtre – et gère le cas où cette dernière est redimensionnée. Mieux, il va automatiquement ajuster la taille des colonnes suivant la quantité de texte dans chaque colonne. Cela demande d’oublier la logique du positionnement de tous les éléments au pixel près, mais permet une très grande simplicité de développement. Avec un GUI traditionnel (encore utilisé dans des logiciels modernes comme Windows 7 ou iTunes), l’utilisateur final doit lui-même redimensionner les colonnes si des informations sont cachées.

Le HTML a d’autant plus été révolutionnaire qu’il a débuté à une époque où le développement d’un GUI s’orientait vers une solution graphique à la Visual Basic (utiliser une interface graphique pour développer une interface graphique semblait des plus logiques).

Maintenant, en quoi un langage au format texte apporte-t-il quelque chose? Le texte a l’énorme avantage de pouvoir être facilement manipulé. Vous voulez créer une copie d’une partie de l’interface graphique et la modifier légèrement? Rien de plus simple en HTML, et ce grâce à des fonctions telles que copier/coller et rechercher/remplacer. En Visual Basic, aucune automatisation n’étant possible, cela demanderait beaucoup de clics de souris et de saisies manuelles de texte.

Mais la manipulation ne s’arrête pas à l’utilisateur mais s’étend à n’importe quel programme. Le fait que le HTML soit du texte a permit un transfert facile du serveur vers le client – d’où un déploiement facile. N’importe quel logiciel peut facilement générer du HTML, et des portions de HTML complètes peuvent être facilement stockées dans une base de données. On imagine mal un serveur Web créer en temps réel un programme Visual Basic en l’envoyer au client – c’est pourtant ce que font les serveurs Web modernes avec du HTML généré dynamiquement.

L’exemple d’un langage de requête de haut niveau

Le SQL est le langage le plus utilisé pour accéder à des données stockées dans un SGBD (le fait qu’il soit simple et au format texte a certainement aidé). Mais le SQL reste un langage de technicien qui nécessite de connaître le fonctionnement d’une SGBD/R (tables, jointures) ainsi que le schéma de la base (comment les données sont agencées).

Les tentatives de trouver un langage de plus haut niveau que SQL se sont souvent orientées vers le langage naturel. Ce dernier pose cependant un problème: étant donné qu’on ne peut pas imposer de grammaire stricte, un programme de langage naturel n’est jamais 100% certain de comprendre ce que l’utilisateur veut dire.

C’est pour cette raison que, pour des besoins professionnels, je me suis lancé dans l’écriture d’un business language destiné à effectuer des requêtes de plus haut niveau qu’un SELECT / FROM / WHERE en SQL. Le langage ne parle pas de table et de jointures mais de clients, de produits, d’enquête clients, etc. Ce langage essaie d’employer des termes les plus proches de l’utilisateur que possible – on précise par exemple une date en disant « last month » (le mois dernier), « last fiscal quarter » (le dernier trimestre fiscal) au lieu d’entrer les dates exactes. Il permet cependant certaines requêtes complexes, comme les clients qui ont le produit X et qui ont passé des appels support contenant certains mots-clé – et afficher la corrélation entre le temps de résolution et la satisfaction du client. Le langage permet même de faire des requêtes qui sont ordinairement difficile à coder, comme l’absence de jointure (chercher les clients qui n’ont PAS un type de produit donné).

Conclusion

L’informatique d’entreprise a grand besoin de logiciels génériques pour gérer son système d’information, les coûts de personnalisation devenant de plus en plus importants.

Nombreuses sont les compagnies qui essaient de s’attaquer à ce problème. Verra-t-on un jour un langage métier qui permette de complètement décrire la manière dont fonctionne une entreprise, permettant une personnalisation facile d’une solution de CRM? Qui sait.

Un tel langage ne doit pas être un langage de programmation mais un langage qui parle à l’utilisateur final. Avec le tableur les comptables n’avaient pas à apprendre un langage de programmation. Juste comment écrire des formules, et plus tard des macros. Pareil pour HTML: c’est un langage de mise en page. Le langage nécessaire ici est un langage de système d’information, où la syntaxe parle aux managers (client, revenu, tarification, produit, service).

Une telle technologie étant disruptive elle aura besoin d’être promulguée par une startup. En effet, elle permettra d’offrir moins de fonctionnalités qu’un CRM ou ERP traditionnel. L’écosystème autour de ces deux produits a donc toutes les chances de rejeter une telle solution. Cette dernière n’accommodant que les PME et demandant moins de travail pour la personnalisation, elle est peu séduisante pour une société de service habituée aux gros projets de customisation de CRM. C’est la raison pour laquelle le pionnier du CRM en ligne est Salesforce.com et non SAP ou Oracle.