Depuis l'origine, le projet «Borsalino» s'est donné un objectif simple : celui de fournir au gestionnaire et au développeur des outils de gestion de qualité avec lesquels il sera agréable de travailler et dont chacun des acteurs aura le contrôle.
Cependant, avec une description si succincte, il est possible de manquer l'essentiel et de passer à côté des caractéristiques qui font de «Borsalino» un projet ambitieux, réaliste et crédible.
En effet, le projet «Borsalino» est sur le point d'entrer dans une nouvelle phase. Pour ce faire, nous avons besoin de rassembler les énergies autour d'un document de référence. Ce deuxième manifeste doit rappeler nos objectifs, décrire plus précisément le projet et ouvrir les perspectives pour la suite de notre parcours.
Borsalino est avant tout un projet au service de l'utilisateur. Mais, pour répondre aux besoins de l'utilisateur encore faut-il savoir à quel utilisateur nous faisons référence.
En général, cette problématique est souvent abordée en segmentant les utilisateurs en fonction de la taille de l'entreprise dans laquelle ils travaillent. Suivant que l'on s'adresse à une Très Petite Entreprise (TPE), une Petite ou Moyenne Entreprise (PME), une grande entreprise ou un grand groupe, le projet est taillé différemment. C'est de cette manière que les éditeurs de progiciels se positionnent aujourd'hui sur leur marché.
Cette approche est trop restrictive et tend à appauvrir le débat. Elle évite finalement de définir les besoins de l'utilisateur et ne sert qu'à déterminer une politique tarifaire. Cette logique a pour résultat que les fonctions offertes à l'utilisateur dépendent de son budget et non pas de ses besoins.
Le projet «Borsalino» est un projet de développement libre. À ce titre, nous pouvons nous abstraire de cette segmentation marketing et proposer une réponse plus opérationnelle.
En effet, les utilisateurs ne constituent pas une population homogène.
Le vrai défi du projet Borsalino apparaît plus clairement. Il s'agit de satisfaire l'ensemble de ces besoins dans une approche unifiant ces différents axes.
Le projet Borsalino a d'abord pour ambition de fournir en standard des outils à même de satisfaire les besoins de différentes professions. C'est l'objet d'un découpage en modules fonctionnels (Comptabilité générale, Gestion de trésorerie, Paie, rapprochement bancaire, etc.).
Pour ce qui est de la prise en compte de la diversité des métiers, il n'est pas envisageable de créer au sein du projet Borsalino des fonctionnalités répondant à des besoins aussi variés. Le projet a vocation à fournir dans un premier temps des outils standards, puis dans un deuxième temps de répondre aux attentes de certains secteurs d'activité. Cependant, il est nécessaire d'offrir à l'utilisateur la possibilité d'étendre ou de modifier certains traitements de l'application pour répondre aux contraintes de son métier et de stocker des données propres à son activité.
Enfin, les utilisateurs souhaitent personnaliser leurs applications, dans leurs fonctionnalités, comme dans leur interface. Il nous faut fournir à ces utilisateurs un moyen de "programmer" leur outil. La réponse habituellement donnée par les progiciels dans ce cas est de fournir un langage de macro-commandes permettant d'étendre le logiciel.
Classiquement, dans un projet de gestion, les utilisateurs font part de leurs besoins à un groupe d'informaticiens. Ces derniers produisent une analyse et réalisent un outil pour les gestionnaires répondant à ce besoin spécifique. Par la suite, ceux-ci sont amenés à formuler de nouveaux besoins, et le processus se poursuit dans une boucle sans fin.
Cette démarche n'est valable que dans un contexte bien déterminé, pour répondre à des besoins d'utilisateurs bien déterminé. Elle tient implicitement compte du contexte. Par exemple, si une équipe informatique doit développer un logiciel comptable pour le responsable comptable d'une société travaillant dans le secteur du bâtiment, la diversité des utilisateurs n'a pas à être intégrée dans l'analyse. Le projet est développé pour le service comptable et non pas pour le contrôle de gestion ou la trésorerie ; il s'inscrit dans le secteur du bâtiment et n'a pas à tenir compte les contraintes légales d'autres secteurs d'activité. Au final, les axes profession/métier/fonction ont été simplifiés pour coller aux besoins des interlocuteurs et uniquement de ceux-là.
Souhaitons-nous aujourd'hui nous attaquer à cette diversité ? Pourquoi ne pas adopter la démarche classique : répondre à un besoin d'un groupe d'utilisateurs, puis étendre petit à petit le domaine du projet ?
Partons d'un exemple concret. Considérons une holding gérant plusieurs sociétés. La plus grosse partie de l'activité du groupe consiste à distribuer dans son réseau de magasin les produits qu'elle fabrique. Il se trouve que sa comptabilité est plutôt orientée sur la partie financière du groupe. La tentation est alors forte, aussi étrange que cela puisse paraître, de se doter d'une nouvelle comptabilité, qui prend en considération la problématique de la gestion d'un réseau de vente. Le problème est que l'on ne peut supprimer l'ancienne comptabilité, qui répond au besoin de l'autre partie du groupe. Le risque est alors de se retrouver avec deux applications, qui ne communiquent entre elles que par le fin canal des programmes d'interface.
Cet exemple n'est pas un cas d'école. C'est le produit de la pression des utilisateurs pour la prise en compte de leur contexte (Profession/Métier/Fonction). La réponse des services informatiques s'inspire souvent du dogme suivant : utiliser chaque produit pour ce pourquoi il est fait. Paradoxalement, nier la diversité semble conduire à l'éclatement.
En réalité, cette diversité existe. Plutôt que de la nier en effectuant des développements ad hoc et peut-être incompatibles entre eux ou en installant différents progiciels pour répondre à différents besoins, il faut dès le début la prendre en considération.
Dès lors que nous souhaitons prendre en considération cette diversité, nous devons procéder d'une autre manière. Mais comment ?
Nous avons souligné la diversité des utilisateurs et de leurs besoins. Elle ressurgit avec acuité, même au sein d'une unique application, dès lors que celle-ci est multi-utilisateur.
Cette notion, au niveau technique met en oeuvre un concept informatique aujourd'hui classique et bien admis : le client/serveur.
En effet, dès lors que plusieurs utilisateurs souhaitent accéder aux mêmes données, l'information ne peut plus être gérée uniquement sur leur poste de travail. Il faut concevoir une zone centrale de stockage de l'information. Pendant que nous y sommes, il est intéressant que cette instance centrale soit également capable d'exécuter des programmes, car les traitements en informatique de gestion sont généralement volumineux et longs. Exécuter ces longs programmes sur une machine centrale permet de libérer celle des utilisateurs pour d'autres tâches.
Il faut alors trouver un moyen de faire communiquer le programme client sur la machine de l'utilisateur et les programmes s'exécutant sur le serveur.
Une réponse classique, là encore, serait de développer un ensemble de fonctions utilisables par les développeurs de programmes client (c'est ce que l'on appelle une API). Certes, cela risque de fonctionner, mais cela pose deux problèmes. Cela ne résout pas la question de la manière dont communique le client et le serveur. Cela implique simplement que l'on utilise certaines facultés de développement distribué : les fonctions tournant sur le client utilisent des facultés internes au langage pour lancer des programmes sur le serveur.
Cette approche comporte plusieurs défauts :
De quelle alternative dispose-t-on ?
Il existe une autre solution classique et éprouvée dans le monde Unix. La création d'un service (Daemon) sur le serveur gérant les connexions des clients par échange d'information sur un canal réseaux (Socket). Dans ce schéma, le client envoie ses requêtes au serveur via ce canal de communication. Le serveur envoie sa réponse par le même canal.
Le principal avantage de cette solution est de permettre à tout type de client de mettre en oeuvre les fonctionnalités du serveur, puisque ce mode de communication est universel. La contrepartie de cette liberté est qu'il faille créer un protocole pour communiquer entre le client et le serveur. Comment sont formulés les ordres envoyés au serveur ? Comment sont agencées les informations renvoyées par le serveur ?
Revenons sur l'ébauche de réponse à la diversité des utilisateurs. Il s'agissait de permettre la personnalisation de leur outil via un langage de macro-commandes. N'avons-nous pas là déjà un moyen d'envoyer des commandes au serveur ? Si, bien sûr ! Nous avons donc un langage macro-commandes ou un protocole (nous pouvons l'appeler de deux manières selon que l'on se place au niveau communication homme-machine ou machine-machine).
Fusionner ces deux notions permet d'unifier les besoins. Notre langage de macro-commande devient un outil de développement pour gestionnaires. C'est un langage qui lui permet d'exprimer ses besoins d'une manière adaptée à son travail. Le rôle du serveur devient alors d'assurer la cohérence des données, la conformité des opérations aux contraintes légales et aux règles de gestion de l'entreprise.
Allons encore plus loin dans la conception du projet Borsalino. Borsalino introduit une étape supplémentaire par rapport à un projet de gestion classique : le développement d'un langage adapté à la gestion. Ce langage doit proposer dans sa syntaxe et dans sa structure la mise en oeuvre des concepts les plus récurrents en gestion (gestion transparente des devises, etc.).
Le développeur quant à lui peut être amené à manier soit un langage classique, soit ce langage de gestion suivant la position qu'il adopte. S'il se place comme développeur du serveur, il utilisera le langage dans lequel il est programmé. S'il se positionne comme développeur d'outil de gestion, il doit en revanche utiliser le langage de gestion pour bénéficier des facilités de ce langage et pour produire du code lisible par le gestionnaire.
Ce langage devient donc une interface universelle entre toutes les entités du projet. Il sert à la communication entre l'homme (utilisateur avancé développant ses extensions) et la machine ; il sert de communication entre machines (protocole); il sert enfin de langage formel entre l'utilisateur et l'informaticien.
Il est souvent affirmé, pour écarter le rôle des utilisateurs avancés que ce n'est pas à l'utilisateur de programmer son application. C'est un travail compliqué, qui demande de l'expérience, sous peine de générer des dysfonctionnements majeurs dans le système d'information.
En réalité, la gestion de la diversité est si primordiale que les utilisateurs sont prêts à tout pour répondre à leurs besoins. Les tentatives de réponses actuelles consistent à donner une illusion de souplesse aux gestionnaires, souvent en les dotant d'outils externes au progiciel pour leur permettre d'accèder directement aux données. Le succès de Business Object et autres requêteurs s'inscrit pleinement dans cette démarche.
C'est en fait à ce moment même que les ennuis commencent pour l'entreprise et que l'on assiste à l'éclatement des traitements et des données. La nécessité de traiter la diversité est en général niée dès l'origine du projet. Après le déploiement du projet, la pression des utilisateurs pour satisfaire leurs besoins est telle que les services informatiques les dotent d'outils externes aux progiciels pour répondre à leurs besoins. Ce sont en règle générale des requêteurs ne permettant que l'accès en lecture directe aux données de l'entreprise. Parfois l'écriture est possible, ou activée par une ruse de l'utilisateur. On imagine alors les dégâts que l'utilisateur est capable de faire. Même dans le cas où il n'a accès qu'en lecture aux données des progiciels, on assiste à un éclatement de l'information et à un démantèlement de la cohérence du système d'information. Les utilisateurs commencent dans les faits à extraire les données de l'application et à les retraiter dans un tableur par exemple. Les forces centripètes deviennent tellement fortes que c'est la cohérence même de l'information dans l'entreprise qui est menacée.
La justification du refus de l'autonomie de l'utilisateur résulte d'une démonstration par l'absurde. Nous donnons à l'utilisateur des logiciels très rigides, mais il fait déjà tellement de bêtises face à de tels logiciels qu'il est impensable de lui offrir des logiciels souples. Dans les faits, l'utilisateur commet effectivement un certain nombre d'erreurs face à son système d'information, parce qu'il cherche avant tout à satisfaire ses besoins donc se voit contraint de tenter par tous les moyens de contourner les rigidités du logiciel.
L'originalité du projet Borsalino est de proposer dès le départ un maximum de souplesse à l'utilisateur, pour donner un cadre sain à son travail de personnalisation du système d'information en le dotant d'un outil propre et performant. Cette stratégie est aujourd'hui la seule permettant d'espérer éviter l'écueil de l'entreprise démantelée.
Même si l'objectif du projet Borsalino vient d'être clairement défini, l'étendue et la complexité du problème rendent en pratique sa conception délicate. Une des méthodes pour simplifier l'analyse et la rendre assimilable dans toute sa complexité par notre cerveau consiste à utiliser une métaphore pour servir de fil conducteur. La métaphore consiste dans l'utilisation de termes concrets, pour rendre plus palpable la présentation de problèmes abstraits.
Les métaphores sont couramment employées dans la conception des interfaces utilisateurs, par exemple, pour résoudre certains problèmes de prise en main et d'ergonomie.
Il existe une approche similaire à celle que nous souhaitons développer. C'est une approche héritée du jeu de rôle. Le jeu de rôle consiste en fait à décrire une réalité et à la modéliser à travers un corps de règles simulant cette réalité.
Cette approche n'est pas totalement étrangère à l'entreprise puisqu'elle sert de base à de nombreuses techniques d'apprentissage du management.
Dans le cadre d'un projet informatique, cette approche en terme de jeu de rôle a déjà été défrichée au travers de diverses expériences. Les plus joueurs d'entre vous connaissent certainement les "muds" (multi-user dungeon: Donjon Multi-Utilisateur). Ces programmes sont des outils d'interaction entre les utilisateurs évoluant sur le serveur. Dans une de ces formes la plus évoluée, le MOO (Mud Orienté Objet) a servi de base à diverses expériences scientifiques et sociales (Etude sur l'émergence de la loi dans les communautés virtuelles, etc.). Le Xerox Park, un des laboratoires informatiques les plus renommés, héberge un des projets de MOO : LambdaMoo.
L'approche "MUD" dispose de plusieurs avantages et similitudes avec le projet Borsalino :
Cette approche est bien implémentée dans un MUD Orienté Objet développé en Python : POO (Pythonic MOO).
L'approche MUD permet de créer un système homogène et cohérent. Elle ne restreint pas le projet et se trouve plutôt être un nouveau vecteur de création. Elle permet notamment de résoudre élégamment et simplement des problèmes complexes.
Dans l'espace utilisateur Borsalino (BUS : Borsalino User Space), les agents peuvent être soit des utilisateurs, soit des services commandés par la machine. Quels qu'ils soient, ils ont besoin d'échanger des informations entre eux pour jouer leur rôle dans le système.
Par exemple, imaginons que l'agent 'MIKL' soit la représentation dans le système de l'utilisateur Mickaël Rémond. Cet utilisateur souhaite obtenir l'état de rapprochement bancaire du mois de décembre 1999. Il va s'adresser à l'agent rapprocheur et lui demander l'état désiré. L'agent rapprocheur va devoir lui-même interroger d'autres agents pour pouvoir effectuer la tâche qui lui est demandée. Il va notamment contacter l'agent banque afin d'obtenir la liste des écritures bancaires du compte concerné pour le mois de décembre, etc. Il finit par renvoyer à l'utilisateur l'état de rapprochement demandé.
Du point de vue du fonctionnement interne du système, les échanges peuvent se faire par transmission de fragments de document XML (eXtensible Markup Language). Ce sont des éléments porteurs de données et de leur propre description. Ils permettent de standardiser l'échange d'information. XML étant en passe de devenir un standard de l'industrie informatique, son adoption dès l'origine du projet est un gage d'ouverture et de pérennité.
Quelles sont les conséquences des principes énoncés précédemment?
Ce modèle offre par exemple la possibilité de développer des agents correspondant à des passerelles vers l'extérieur de l'espace Borsalino.
Cet agent peut être le représentant d'un autre espace Borsalino (BUS). Cet agent prend la même forme qu'un utilisateur et se voit attribuer des droits gérés de manière similaire. En communiquant avec cet agent, un serveur Borsalino peut échanger des données avec un autre serveur Borsalino. Cet échange se fait de manière transparente pour les utilisateurs et les autres agents évoluant dans le même espace. La communication s'établit par réciprocité : un agent créé dans l'espace utilisateur d'un serveur Borsalino par un autre serveur entraîne la création d'un agent dans son propre espace par ce serveur, afin que la transparence soit parfaite dans chaque environnement et que les autorisations soient correctement gérées.
Cette possibilité d'échange avec l'extérieur s'étend aux applications non Borsalino dans l'entreprise. Il est possible de développer un agent d'interface évoluant dans l'espace Borsalino chargé d'établir la passerelle entre les deux applications. Puisque les données sont échangées sous forme XML, l'intégration avec les futures applications de l'entreprise est assurée. Pour la communication avec des applications plus anciennes, il faudra que l'agent fasse office de parseur/générateur de XML.
Cette possibilité d'ouverture sur l'extérieur vient bien sûr en complément des possibilités offertes à toute application d'être un simple client du serveur Borsalino.
Les possibilités et analogies résultant de notre approche sont nombreuses et stimulantes. Nous n'avons fait dans cette deuxième partie qu'effleurer le sujet. J'espère en avoir suffisamment dit toutefois pour vous donner envie de participer activement à notre aventure et à nos cogitations.
Aujourd'hui le projet Borsalino s'inscrit résolument dans la direction de la souplesse, de l'ouverture et de l'innovation. Il offre des outils de communication entre les futurs utilisateurs du projet en leur permettant de travailler dans un espace commun et d'échanger autour du même langage. Il indique une direction dans laquelle nous allons poursuivre nos travaux de conceptualisation et de dessin d'architecture.
Même s'il est encore tôt pour déterminer définitivement de quelle manière sera architecturée l'application, nous pouvons imaginer une première ébauche d'organisation :
_______________________ ________
Outil de développement | | | |
pour gestionnaire <---->| PROXY |-->|Borsa |
| (Routage) | | |
| (Authentification) | |Exécu-|
Client d'un utilisateur<---->| (Journalisation) |-->|-tant |
simple | etc. | | |
|_____________________| |______|
\ /
\ /
\ _____/_____
\| |
| Base |
| de |
| données |
|_________|
Chacune des grandes entités décrites ici peut être conçue indépendamment des autres.
Ceci nous amène donc à un plan d'action et une méthodologie de travail. Je vous propose donc deux axes de réflexion, qui peuvent être approfondis de manière distincte et parallèle :