Choix méthodologiques

La tactique adoptée sera celle des «petits pas». Réaliser des petits modules fonctionnels et utiles, voilà pour le moment en tout cas notre seule ambition.

La première tâche sur laquelle nous comptons nous atteler est la réalisation d'un outil de rapprochement bancaire.

Pourquoi commencer par un projet de rapprochement bancaire ?

• Parce qu'aucun produit de rapprochement bancaire vraiment parfait n'existe à ce jour sur le marché. Ce projet est donc très utile.
• Parce que les traitements et les opérations mises en oeuvre restent relativement simples.
• Parce que ce projet est à la croisée des chemins de la comptabilité et de la trésorerie et permet déjà de mettre en place certains schémas et certains principes de fonctionnement dans les deux directions.
• Parce que je connais très bien le sujet et que le pilotage fonctionnel du projet n'en sera que plus direct et moins hésitant.
• Parce que les applications de rapprochement bancaire sont par nature multiplateformes ou du moins multi-applications. En effet, ce type de progiciel est souvent contraint de récupérer des données à la fois de la banque et de l'application comptable. Le fait que cette application soit sur une autre plate-forme (par exemple Linux) ne sera donc pas handicapant pour une utilisation professionnelle de l'outil.
• Parce qu'il permet de constituer les équipes, de mettre en place la méthodologie et de proposer rapidement un module fonctionnel comme base à d'autres développements.

En travaillant d'abord sur le rapprochement bancaire, l'équipe a toutefois vocation à étendre son domaine de compétence à d'autres domaines de l'informatique de gestion.

Contrairement aux apparences, ce projet ne s'intéresse pas seulement aux grosses PME et aux grandes entreprises. Le projet part du postulat qu'il y a plus de différences commerciales que fonctionnelles entre les deux cibles.

Lorsque l'on analyse l'offre et la politique commerciale des éditeurs, on constate que la différence entre un produit "light" (à destination des petites entreprises) et sa version "pro" (pour les plus grosses structures) réside en général dans la souplesse, la capacité d'évolution et de personalisation du comportement du produit.

Par conséquent, si l'on pense le projet comme directement modulaire et hautement paramétrables, il est possible de proposer un modèle de comportement standard satisfaisant les PME, tout en laissant de grande possibilité d'adaptation pour des besoins particuliers.

Cet aspect est rendu possible par la démarche originale du projet. Il ne s'agit pas de traiter de manière simplifiée toutes les fonctions informatiques à assurer par l'entreprise mais plutôt de ce concentrer d'abord sur certains de ces besoins et y répondre de manière complète. Il s'agit de développer des outils conformes à la philosophie Unix : Réaliser des programmes effectuant des tâches précises et capable de travailler sans problème avec d'autres outils conformément aux préférences de l'utilisateur.

La méthode d'analyse

Christian Momon a proposé de commencer par s'appuyer sur une méthode d'analyse orientée objet simplifiée. c'est pour le moment la méthode qui sera adoptée dans les échanges au sein de l'équipe du projet Borsalino. Il s'agit d'utiliser un formalisme qui permet à tous de se comprendre sans ambiguïté.