Zéro spécifique

Véritable plaie des logiciels métiers, les développements spécifiques peuvent être évités grâce à la programmation dynamique. Voyons un peu ce que ce zéro spécifique signifie dans ecsy.

En théorie, un logiciel métier est, comme son nom l’indique, une boite à outils contenant tout le nécessaire pour l’exercice d’un métier particulier.

Je dis en théorie parce que, s’il existe des métiers aux contours parfaitement définis dans leurs procédés et informations par des outils informatiques bien rodés, il en est d’autres pour lesquels ce n’est pas le cas.

Client agnostique

La gestion des surfaces et de l’occupation (space management) fait partie de ces métiers aux définitions et contraintes parfois un peu floues et dont la pratique peut sensiblement varier d’un client à l’autre.

A contrario, la comptabilité est un métier parfaitement bien défini. Deux logiciels de comptabilité ne pourront guère différer que par leur ergonomie puisque la liste des fonctionnalités attendues est finie. Tous comptes faits si je puis dire, l’éditeur d’un logiciel de comptabilité n’a qu’un seul client, l’Etat (je simplifie à dessein). En effet c’est lui qui décide des règles et établit la liste des fonctionnalités. Les acheteurs du logiciel sont en réalité dans la même situation que des utilisateurs n’ayant pas le loisir d’exercer leur métier autrement.

Le space management est un métier autrement plus délicat à « programmer ». Il n’existe pas de pratique universelle et pas de « client central » pour établir les règles communes.

Programmer ecsy c’est d’abord tenter d’extraire les fondamentaux des pratiques de terrain pour produire les outils « client agnostique » (en jargon informatique), c’est-à-dire suffisamment génériques pour être utilisés indépendamment des particularités de tel ou tel client.

Mais pour les raisons que je viens d’exposer, il est impossible de prétendre prévoir tous les cas de figure. Tel client aura inévitablement un besoin non couvert. Après cette longue introduction voyons maintenant un peu plus concrètement comment ecsy fait face à cette difficulté.

Son truc en plus

Le cas le plus simple concerne la gestion d’une donnée supplémentaire. Pour tel client, à tel endroit, il manque la possibilité de saisir un numéro de téléphone. Et dans ce cas précis, admettons qu’il ne nous paraisse pas pertinent de proposer de l’ajouter au standard ecsy lors de la prochaine mise à jour.

Qu’à cela ne tienne, le « moteur » dynamique d’ecsy permet au client d’ajouter son truc en plus. Avec bien entendu les contraintes de saisie idoines et la maîtrise complète des droits d’accès en lecture et écriture.

La plupart du temps, les besoins spécifiques se limiteront à ce genre de situation. Mais le modèle de programmation dynamique que nous utilisons dans ecsy permet d’aller beaucoup plus loin dans la personnalisation.

Prenons tel autre client qui désire gérer les revêtements de sol dans ecsy. Il veut pouvoir maintenir un catalogue(moquettes, dalles, parquet, etc.) avec le fournisseur pris dans la table des tiers d’ecsy. Evidemment, il veut aussi pouvoir déclarer que tel local est équipé de tel revêtement de sol.

Oui, tout cela est possible sans toucher le moins du monde à l’application c’est-à-dire sans faire le moindre développement spécifique.

Insigne qui veut dire zéro

Oui cher client, tout cela est bien beau, mais que se passe-t-il lors des montées de version de l’application ? Rien, c’est absolument transparent, vous n’avez rien à faire, vous continuez à travailler comme d’habitude. Vos personnalisations sont toujours là, inchangées.

C’est ça le zéro spécifique ecsy.