Suite du mémoire et conclusions – Chapitre 9 :
1- Terminer ce mémoire
Nous terminons ce mémoire, en ayant suivi les objectifs, excepté notre semi-échec concernant les logiciels libres. Cependant, au fil de la réalisation de ce travail, d’autres objectifs potentiels sont apparus, ce qui nous fait dire que si ce travail est terminé par rapport aux objectifs de base, il ne l’est pas tout à fait. Il s’agit de points qui pourraient être améliorés, ou encore de points auxquels nous n’avions pas pensé au moment de l’établissement des objectifs initiaux. Ils pourraient faire l’objet de développement ultérieurs.
2- Recommandations pour la suite de ce travail
Ce travail pourrait être poursuivi en développant les aspects que nous décrivons ci-après.
3- Recherche sur les logiciels libres
Nous avons failli quant à l’objectif de n’utiliser que des logiciels libres, ayant dû acquérir une licence d’utilisation de la suite logicielle <oXygen/>XML. Il est probable qu’en se concentrant sur ce point uniquement, une solution libre aboutisse. Nos recherches (que nous avons dû limiter faute de temps) ont montré qu’il existe diverses solutions libres, mais non regroupées au sein d’une même suite, et surtout pas très ergonomiques et encore moins documentées. Par regroupement, nous entendons un éditeur XML doté d’un parser , un logiciel Xquery, voire un traitement XSL et encore mieux, un formatter, le tout accessible via une plate-forme unique. Idéalement dotée d’une interface graphique. Simplement exprimé, la même chose que <oXygen/>XML, mais en licence libre et s’installant sous Linux. A notre sens, XQDT (pour XQuery) sous la plate-forme Eclipse est une très bonne base moyennant un minimum de documentation.
4- Repenser le document XML
La méthode que nous avons utilisée pour représenter l’ensemble des données comptables, relatives aux commandes, etc… au sein d’un même document XML pourrait être revue si le volume d’information devenait important. Pour quelques milliers de saisies, et relativement peu d’éléments, cela convient. La redondance de l’information (par exemple pour les postes pcmn) rend sa maintenance laborieuse et comporte un risque d’erreur. Plus d’information et plus d’éléments augmenterait cette redondance. Il serait alors intéressant de développer un support pour ces informations XML ayant recours à un ensemble tables plutôt qu’un document XML unique.
5- Travailler l’ergonomie
Un travail portant sur l’ergonomie doit être réalisé. L’utilisateur final ciblé, c’est à dire les gérants de TPE et PME sont très peu friands, voire réticents à toute forme de travail administratif, pour utiliser un terme global. Cela relève très souvent de la corvée, et est sans cesse reporté au lendemain. Si il doit être utilisé, il importe donc que ce projet ABC soit très bien présenté, et de façon la plus simple possible à manipuler. Saisir les informations XML « manuellement » dans le document XML est impensable. Nous l’avons pratiqué dans le cadre de ce travail, c’est très fastidieux, et générateur d’erreurs. A notre sens, le recours à un système de fenêtres de saisie, donc une interface graphique est nécessaire.
6-Organisation de l’interface graphique.
Une interface graphique pourrait être organisée selon différents thèmes.
Interface orientée vers les données de fonctionnement de l’entreprise.
L’interface concernerait la saisie, lecture et correction/suppression des données relatives aux mesurages, imputations des pièces comptables, et données relatives aux commandes.
Interface orientée vers les données système.
Une autre interface pourrait donner accès aux données qui régissent le fonctionnement de l’application. Il s’agit essentiellement des proportions de répartition des charges indirectes et des familles de coût, mais aussi de la gestion des comptes pcmn autorisés, clients autorisés. L’action porte ici sur la DTD et fichier XML.
Interface orientée vers la structure du système.
Cette interface permettrait de modifier ou de créer des activités, familles de coût, mais aussi d’ajouter des éléments inexistants dans la forme actuelle. L’action porte ici sur la DTD et fichier XML.
Interface orientée consultation / requêtes.
Une interface graphique accédant les requêtes XQuery est nécessaire également. L’apprentissage de XQuery est long, et nécessite une parfaite connaissance de l’arbre XML de base. A nouveau, ce n’est pas là tâche pour l’utilisateur final. Il serait possible de proposer une série de requêtes par thèmes. – Recherches par commande: des détails quant aux mesurages relatifs à telle commande, la part de charges indirectes pour telle commande,.. – Requêtes de calcul: le coût d’une unité d’oeuvre, la valeur de toutes les charges indirectes sur une période, le coût d’une famille,… Une alternative serait un canevas de requêtes « préfabriquées » qui seraient composables via des objets graphiques (cf. Stylus Studio). 
D’autres solutions sont bien entendu possibles. L’utilisateur final devrait idéalement voir de la requête: – une fenêtre où saisir la(es) condition(s) de sélection imposée à la requête; un choix pourrait lui être proposé; par exemple un choix entre les identificateurs de commande. – une icône « start » lançant la requête. En retour, un affichage du résultat à l’écran ou l’impression d’un document de synthèse semblable à celui que nous créons dans le dernier chapitre sont proposés.
7- Autres fonctions des interfaces :
Ces différentes vues pourraient proposer un filtrage par utilisateur, par exemple pour éviter des modifications des règles de calcul par un utilisateur non-initié, ou ne pas autoriser l’accès aux requêtes de résultats à tous. L’interface devrait avoir également quelques fonctions propres, comme la création automatique d’identificateurs uniques à chaque saisie (sans intervention de l’utilisateur). Ou encore lorsque le choix des valeurs pour un attribut est défini dans la DTD, ces différentes possibilités pourrait être proposé à l’utilisateur par menu déroulant.
8- Technologie pour les interfaces :
Au terme d’une très brève recherche, il semble que Xul ou Xforms pourraient être des solutions pour les interfaces, dans l’esprit XML. – Xul (XML-based User interface Language) créé pour le projet Mozilla, utilise un langage ayant une structure XML pour créer des interfaces graphiques. – Xforms, une recommandation du W3C depuis 2003, qui est en constante évolution.
9- Les requêtes XQuery :
Nous restons avec une interrogation à propos de l’aspect « low level » de XQDT évoqué précédemment, que nous avons généralisé à XQuery , à tort ou à raison, partant du principe que XQDT est un outil de recherche XQuery. Nous n’avons pas approfondi, la question reste ouverte. Si comme nous le suggérions, l’aspect low level peut se traduire par la nécessité de devoir appliquer une série de requêtes successives sur un arbre XML pour obtenir un résultat plus raffiné que les données du document XML de base, il serait intéressant d’automatiser ces enchaînements de requêtes. L’utilisateur ne devrait voir qu’une seule requête, la première, et lui demander de fournir les résultats raffinés … de la dernière requête.
10- Conclusions :
Au terme de ce travail, force est de constater qu’il est possible de mener une démarche de comptabilité analytique en utilisant les technologies XML. En dressant la liste des objectifs, nous avions un doute quant à la possibilité de transformer les données chiffrées sans avoir recours à un langage de programmation classique. Parmi les solutions de sélection et transformation de données XML, nous avons retenu XQuery, qui s’est révélé suffisant pour mener à bien les opérations que nous souhaitions effectuer sur ces données chiffrées, et ainsi produire les résultats attendus. Pour produire des ratios, donc raffiner l’information de base, nous avons dû créer une succession de requêtes FLWOR, peut-être est-ce là la limite de XQuery: ne pas pouvoir effectuer cette transformation en un seul traitement. La méthode que nous avons tenté de développer permet grâce aux technologies XML un très intéressant découplage entre les données de base (le document XML) et le traitement (XQuery) des informations contenues. Par rapport à une expérience précédente organisée autour d’un tableur , le risque de perte ou de modification accidentelle des informations de base est très réduit. Et nos données ont l’énorme avantage de ne pas être tributaires d’un format propriétaire. Par contre, notre objectif de réaliser ce mémoire en n’utilisant que des logiciels libres a failli dans une certaine mesure. Pour une suite de logiciels assurant les différents traitements XML, nous avons dû opter pour le choix d’une solution payante. Les solutions XML libres que nous avons pu trouver étaient soit trop complexes à installer sous Linux, soit très difficiles d’usage, du moins pour notre niveau de connaissance, ou encore trop peu documentées. Ce point pourrait être retravaillé. Ce travail n’est à notre sens pas entièrement terminé. Plusieurs points peuvent être approfondis. Citons l’ergonomie, qui devrait être améliorée par une interface graphique, ou la méthode de stockage des informations qui pourrait être plus efficiente sous forme de tables plutôt que sous forme d’un document XML unique. Lire le mémoire complet ==> (Application de la méthode Activity Based Costing, technologies XML) Mémoire présenté en vue de l’obtention du grade de Licencié en Informatique et Sciences humaines Université libre de Bruxelles, Faculté des sciences sociales politiques et économiques
