Quelques réflexions sur les pratiques observées au sein ses monnaies locales en matière d’informatisation.
Plusieurs sujets sont régulièrement mis en discussion :
- La nécessité d’une intégration entre les parties logicielles qui gèrent la circulation de la monnaie proprement dite et la comptabilité de l’association.
- Le souci de n’utiliser que des applications open source pour éviter de se mettre entre les mains d’entreprises qui fournissent des solutions logicielles propriétaires qui supposent forcément un prélèvement en continu d’une rémunération.
2 bis) Souvent, on y ajoute le souci d’éviter le plus possible d’utiliser les outils des grandes plateformes telles que Google ou Apple avec leurs DOS qui équipent la majorité des smartphones (Android et IOS).
- La volonté de promouvoir une forte mutualisation entre les solutions logicielles utilisées par l’ensemble des monnaies locales, notamment lorsqu’elles veulent passer à la monnaie numérique.
Des lors, il s’agit de se demander quels sont les arguments avancés pour justifier ces choix stratégiques.
1) Intégration entre la circulation de la monnaie et la comptabilité de l’association gestionnaire :
L’association qui gère une monnaie locale se doit, notamment lorsqu’elle touche des aides publiques d’effectuer un suivi scrupuleux de ses comptes. Donc, à développer des programmes informatiques, autant le faire à la fois pour sa comptabilité interne et pour le suivi de la circulation de sa monnaie qui intéresse l’ensemble des utilisateurs.
Mais la lecture et la bonne compréhension de documents comptables n’a jamais été à la portée du premier venu, ce qui explique la nécessité juridique de l’expertise comptable pour une certification indiscutable.
Les flux de circulation de la monnaie locale se font à 95 % en dehors de la comptabilité de l’association elle-même.
En résumé :
- Le change € contre MLC, avec les € qui vont sur un fonds de garantie, inscrite comme une dette envers tous les possesseurs de MLC
- La reconversion MLC contre € qui débite le fonds de garantie et crédite le commerçant qui reconvertie ses unités de MLC,
- Reste encore les adhésions ou cotisations à l’association lorsqu’elles sont payées en unités de MLC, qui va être comptabilisée comme une recettes en €.
- Reste , mais hors comptabilité de l’association, la circulation de MLC entre le siège central et différents groupes locaux et/ou bureaux de change locaux, avec des flux inverses en €.
Alors pourquoi s’évertuer à développer cette intégration. Les seuls points de jonction incontournables entre la comptabilité de l’association et la circulation de la MLCC se situe donc à deux niveaux :
- dans le fait que l’association est elle-même utilisatrice de la monnaie locale pour ses recettes ( cotisations) et ses dépenses.
- Dans la facturation des frais de reconversion et/ou d’autres taux appliqués au moment des changes € contre MLC ou MLC contre €
Ces deux seuls flux peuvent très bien être traités en dehors du système informatique qui gère la circulation de la MLC.
2) Le choix des seuls logiciels open-source :
La volonté affichée de l’utilisation des logiciels en open-source est fort louable de point de vue militant. Sur un plan économique et politique général, il faut en effet s’opposer à la puissance économique acquise par les multinationales du traitement de l’information à usage professionnel ou privé. Mais, je pense que cela finira par passer par l’application de législation européenne ou mondiale de type loi antitrust ou de type RGPD.
Pour le reste, il ressort surtout de ma pratique de nombreux logiciels open-source trois éléments un peu déplaisants à l’usage :
- Au niveau de l’expérience utilisateur, Il faut davantage de connaissances en informatique, être un peu « geek »,
- Leur fonctionnement présente plus de limites, difficultés, mauvaise adaptation à tous matériels hard,
- Leur maintenance et stabilité dans le temps laisse souvent à désirer.
Quand il n’y a pas de licence commerciale, il manque régulièrement des financements pour des développement nécessaires ou des maintenances rapides et efficaces. Il arrive très souvent pour pallier à cette absence de recettes régulières pour payer du travail de développement ou de maintenance que l’on soit obligé de passer par des subterfuges : le logiciel open source est gratuit pour tous mais l’accès à toute documentation qui évite à un informaticien de décrypter de A à Z tout le programme est payante. Et je l’entends souvent, l’open-source « est libre mais pas gratuit »
3) Le choix de la mutualisation des outils informatiques :
La mutualisation de nos outils, en particulier informatiques, part également d’un sentiment très positif. Les associations qui gèrent des monnaies locales ont de faibles moyens financiers et elles se trouvent devant les mêmes problèmes informatiques à résoudre, d’où l’idée de développer des solutions paramétrables pour plusieurs MLC.
Pourquoi pas ? Mais cela soulève deux difficultés majeures :
- Les MLC ne sont au même stade de développement de leurs solutions informatique, notamment de la monnaie numérique. La solution mutualisée qui serait proposée doit donc s’adapter à cela, y compris en prévoyant des participations financières claires pour chaque monnaie, compte tenu que les plus avancées auront dû payer des développements dont les moins avancées vont profiter. Pour ma part, je pense que la proposition d’une participation « libre et en conscience » est plus idéologique qu’efficiente. Sous le faux prétexte d’aplanir les différences des niveaux de ressources, cette attitude les passe sous silence sans aucune transparence réelle.
- Une seule solution, une seule équipe de développement et de maintenance risque d’aboutir à deux limites :
- On supprime l’effet « émulation » qui peut exister lorsque plusieurs solutions sont en concurrence et créent des approches originales et des sous-programmes particuliers.
- On risque de se passer de compétences existantes dans les différentes associations qui sont prêtes à travailler pour leur monnaie, mais plus difficilement pour un « pôle informatique mutualisé ».
