Publication et premier déploiement au sein de l'Etat d'une comptabilité libre

Posté par . Modéré par j.
Tags :
0
3
avr.
2007
Python
Le code source d'ERP5 M9 vient d'être publié en licence GPL sur le site Admisource à la suite d'un déploiement réussi au sein de l'Agence de l'eau Artois Picardie. C'est probablement le premier déploiement au sein de l'État français d'un logiciel libre de comptabilité. C'est aussi une preuve de plus de l'intérêt croissant des administrations et des entreprises pour les logiciels libres de gestion. Le déploiement a été effectué en interface Web sur des navigateurs Firefox.

Outre le plan comptable M9, ERP5 M9 intègre 22 workflows dont 4 spécifiques à la comptabilité M9, ainsi que 19 rapports (une trentaine prévus à terme). Il s'agit donc d'une application complète capable de traiter la comptabilité publique conformément à l'instruction codificatrice M9-1. Elle partage l'ensemble de son code avec ERP5, le progiciel libre de gestion conçu autour de Zope et développé en python. Il est également prévu d'intégrer les développements réalisés pour ERP5 M9 à ERP5 M14.
  • # pas le premier

    Posté par . Évalué à 6.

    Désolé mais cela n'est pas le premier déploiement au sein de l'État français d'un logiciel libre de comptabilité. Il y a Jefyco (voir www.cocktail.org) sous licence Cecill qui existe depuis pas mal de temps (sources disponnibles sur le svn du CRU).
    Jefyco est utilisé dans une bonne partie des d'établissements de l'enseignement supérieur.
  • # Bonne nouvelle ?

    Posté par . Évalué à 2.

    Est ce que c'est une bonne nouvelle ?
    En prenant consience des galères en maintenance des sites Zope/CPS dans les administrations sur des sites à gros volume ?
    Et aussi en réfléchissant à la pérénité de la technologie Zope2 ?

    Bon s'en est une pour le libre c'est déjà ça :-)
    • [^] # Re: Bonne nouvelle ?

      Posté par (page perso) . Évalué à 2.

      c'est quoi le problème avec la pérénité de Zope2 ?

      je ne vois pas en quoi zope2 agonise comme tu le dis sur ton site.

      en te remerciant à l'avance pour ta réponse argumenté

      RM
      • [^] # Re: Bonne nouvelle ?

        Posté par . Évalué à 5.

        Je répond pour mon cas : Zope 3 existe depuis quelques années et est défini comme "l'objectif à atteindre". La preuve : toute cette histoire de Five (Zope 2.5), etc ... Donc même si Zope 2 est toujours d'actualité aujourd'hui, j'ai plus l'impression que c'est pour des histoires de rétro-compatibilité. Et ça fait un bout de temps que cette migration dure, en plus.
        • [^] # Re: Bonne nouvelle ?

          Posté par (page perso) . Évalué à 3.

          non il n'est pas question de retro-compatibilité, zope3 ne sera jamais compatible avec zope2, ni l'inverse.

          ce sont 2 outils
          mais zope2 ne sera pas non plus abandonné, de très grosses applications tournent en zope2 et des version de maintenance ou d'évolution sortent régulièrement dans les diverses branches.

          le 25 mars, 3 versions de zope 2, de différentes branches (2.8, 2.9, 2.10) sont sorties
          j'appelle pas ça une agonie, ce projet est encore bien vivant
    • [^] # Re: Bonne nouvelle ?

      Posté par . Évalué à 2.

      Pardon ? Je peux avoir une idée qui justifie ces propos... que je ne vais pas qualifier ?

      Un peu ras le bol des gens négatifs qui ne savent pas sur quoi cracher, et qui prennent pour cible des choses qu'il ont fait, et qu'ils ne font plus. Alors justifie toi, donne des arguments, et parle aussi de ton histoire, de ce que tu as fait pour arriver à de telles conclusions hâtives. Ca me fera plaisir.

      Il y a plein de gens qui s'éclatent avec Python (toi encore, ou bien même Python c'et foireux ?), avec Zope, 2 et 3, avec Zwook (sympathique petit CMS fait par des gens bien, qui ne se prennent pas pour les leaders du monde), avec ERP5, et bien sûr avec Plone.

      Mais c'est vrai qu'il faut savoir coder pour utiliser ces technos. Ca pose des problèmes à plus d'un.
  • # Screencast en Flash ...

    Posté par . Évalué à 8.

    Pour ceux qui se réjouiraient de regarder les jolies vidéos et qui veulent rester "libres", laissez tomber : c'est du Flash. J'ai pas réussi à trouver la vidéo "source", même s'il semble qu'en fait, le pire, c'est que c'est généré à partir d'un projet libre (pyvnc2swf) et que ce n'est pas vraiment de la vidéo, mais du vectoriel.

    Bref, aujourd'hui j'ai l'impression que flash est devenu un "standard" du web, comme le HTML de MS était un standard à une époque. C'est triste.
    • [^] # Re: Screencast en Flash ...

      Posté par . Évalué à 3.

      une question de Newbie :
      Qu'est ce qui existe, en libre, pour rempacer le flash ? SVG ? ogg théora ?
      • [^] # Re: Screencast en Flash ...

        Posté par (page perso) . Évalué à 4.

        Au niveau du lecteur, Gnash commence à bien fonctionner, mais ne permet pas encore de lire les flux multimedia.

        Par contre, pour les sites flash qui ne sont pas trop interactifs, ça fonctionne.

        Sinon, au niveau du standard, je crois que flash est surtout utilisé par des gens qui ne veulent surtout pas faire comme tout le monde ... Donc je ne sais pas si un standard concurrent serait très utile.

        Pour la diffusion multimedia, il y a quelques petits trucs en java et javascript, mais rien qui soit très diffusé.

        Adhérer à l'April, ça vous tente ?

        • [^] # Re: Screencast en Flash ...

          Posté par (page perso) . Évalué à 6.

          Ben en fait le soucis est que tu a deux choix pour diffuser de la vidéo.

          1 - le lecteur multimedia du système (mplayer, windows media player, vlc)
          Pour ce faire c'est facile, une balise embed avec les bons paramètres et ça roule.
          Le seul soucis est que ton système destinataire doit avoir les codecs installés pour lire ta vidéo+audio...
          ogg+theora/windows comment dire ah ah ah (rire jaune)
          wmv+wma/linux comment dire ah ah ah aussi
          Un autre soucis est que le flux est souvent pas "seekable" (on peux pas se déplacer dedans), après ça vient peut-être de mon mplayer j'ai pas trop cherché.

          Le javascript va juste permettre de générer la balise pour le flash ou le lecteur intégré (mais bon aucune idée si la détection des codecs en javascript marche)

          2 - le lecteur flash
          Pour ce faire c'est aussi facile, une balise embed avec les bons paramètres et ça roule.
          Tu dois juste avoir le plugin-flash installé (qui s'auto-installe sur tous les navigateurs ou presque)
          Pas de soucis de codecs ni de seeking, mais besoin d'une architecture qui supporte le flash (x86) et du plugin proprio.

          3 - le lecteur java
          C'est une solution qui a pointé le bout de son nez il y a quelque temps, a savoir utiliser un applet java pour lire la vidéo.
          C'est standard, toujours pas libre et surtout flash est installé presque nul part...

          Bref, autant dire que il y a vraiment pas plus simple que d'utiliser un applet flash pour lire un flv...
          • [^] # Re: Screencast en Flash ...

            Posté par . Évalué à 2.

            D'un côté, ce qui est drôle, c'est que ces plugins flashs n'ont fait que standariser un format vidéo (.flv) avec un lecteur standard (même si les players sont différents, je supposent qu'ils utilisent tous le même composant interne à Flash).

            On aurait pu faire pareil en diffusant un bon plugin MPEG-4 ou Ogg Theora, avec les paramètres en plus standarisés à la balise embed pour les contrôles avancés. Et que tout ça soit disponible par défaut sous chaque OS, ou alors au moyen d'un tout petit installeur. Oui, c'est toujours le problème du "par défaut", mais flash, il faut bien l'installer ! Il vient pas tout seul !

            Bon OK, ça ne règle que le problème de la vidéo : mais c'est un des plus gros aujourd'hui en Flash, je trouve.
            • [^] # Re: Screencast en Flash ...

              Posté par . Évalué à 1.

              Oui, mais adobe sort le porte monaie pour faire installer le lecteur flash sur les machines avant qu'elles arrivent chez l'acheteur. Qui dans le libre peut s'amuser a faire pareil ?

              Aujourd'hui, flash, c'est un standard de fait, pas mal documenté. GNU a pris la bonne décision en choisissant d'en implémenter un lecteur. Pas la peine d'inventer un niemme standard !
  • # erp en html ?

    Posté par (page perso) . Évalué à 1.

    Moi ca me choque quand meme un peu, aujourd'hui on parle d'ergonomie et de puissance.

    Je m'explique, dans leur screencast on voit l'exemple de fiche pour les bordereaux et on le voit changer de fiche avec le loading HTML entre chaque fiche. Personnellement moi ca me choque un peu, surtout que je connais quelques clients qui ferait la tronche avec ca :/

    Ergonomie, peut on faire une ergonomie soutenue en HTML+javascript ? Peut on faire des mask edit temps réel afin de minimiser un maximum les erreurs ?

    Je sais que SAP propose un module "client" leger pour son ERP en html mais c'est vraiment une roue de secours, car comparé au client lourd la souplesse n'est vraiment pas la meme..
    • [^] # Re: erp en html ?

      Posté par (page perso) . Évalué à 5.

      Heu faut voir aussi le load de ton application...

      Faire du html(python|php)+css simple avec de form lourde ça a de sacré avantages :
      - vérification des entrées utilisateur
      - vérification de type
      - légèreté sur le navigateur
      - fonctionne avec tous
      Les moins :
      - reload de page complète
      - temps de rechargement (enfin en réseau local sur charge mineure y a pas de soucis)

      Faire du html+javascript+css ça veux dire que :
      - page plus légère, rechargement des seules zones en question
      - sauvegarde en continue
      - impression d'interactivité

      En revanche :
      - tu fout a la poubelle tous les navigateurs qui supportent pas le javascript (ou le tiens)
      - tu dois te taper des vérifications dans tous les sens :
      => javascript et utf8 tu écris une fois, tu testes partout...

      Bref, le web2.0 c'est bien, mais c'est vraiment double boulot !
      (sans parler du javascript qui est un langage vraiment compliqué dès que tu veux faire un truc complexe)

      Bon je connais pas le python, mais seulement principalement le php, donc zope c'est peut-être nettement plus lent que du php(réputation tout ça...), mais j'ai considéré qu'en codant proprement ça devait être quif quif.
      • [^] # Re: erp en html ?

        Posté par . Évalué à 2.

        donc zope c'est peut-être nettement plus lent que du php

        Ce qui est puissant avec zope c'est ZEO:
        ZEO permet à plusieurs processus, instances zopes dispatchés sur plusieurs machines d'être couplés en un système d'objet transactionnel.

        Pas mal d'infos là : http://www.zope.org/Products/ZEO/ZEOFactSheet

        Je ne connais pas d'autre serveur capable de cette prouesse.
        • [^] # Re: erp en html ?

          Posté par . Évalué à 2.

          Je confirme. On parle ici de clustering applicatif à chaud. Il n'y a d'équivalent que dans des technos proprios, assesz haut de gamme.
    • [^] # Re: erp en html ?

      Posté par . Évalué à 1.

      le genre de truc que je pense depuis des lustres, et que ça m'a fait parfois passer pour un martien : le HTML est une regression épouvantable pour l'utilisateur final par rapport au client lourd classique, mais le HTML est super génial du point de vue de certains informaticiens...
      • [^] # Re: erp en html ?

        Posté par . Évalué à 1.

        Le client lourd c'est .... LOURD.
        pour installer sur quelques postes, pas de problèmes, mais pour déployer sur des centaines ou milliers de machines c'est l"enfer.
        En général ils s'appuient sur un composant incompatible avec une autre appli necessaire sur le meme PC, genre pas la même JVM, ou pas la même version de client Oracle, ou ...
        et la commence l'enfer pour gérer les postes de travail.
        Ajoutez a ça la complexité des upgrades des applis une par une ...

        Le résultat c'est que beaucoup de boites "virtualisent" les clients lourd en les déportant sur un serveur Citrix => augmentation du cout (serveur + licenses + ...)

        Donc le client leger HTML/AJAX/Javascript possède bien des avantages, il est juste dommage que l' IHM en souffre.... faudrait peut-etre utiliser le moteur IHM de mozilla ?

        En attendant, SAP mais aussi PeopleSoft sont en HTML sur IE.
  • # M9

    Posté par (page perso) . Évalué à 4.

    hum c'est quoi le rapport avec http://fr.wikipedia.org/wiki/M9 :)
    une norme comptable je suppose, bonnes pratiques toussa ? c'est européen ou que français ?

    bon au moins M14 c'est un peu plus clair : "cadre juridique qui réglemente la comptabilité des communes françaises" http://fr.wikipedia.org/wiki/Instruction_budg%C3%A9taire_et_(...) donc franco-français

    Ce genre de règles existe aussi au niveau européen je suppose ? Déjà que j'avais cru comprendre que grisbi intégrait des règles comptables (TVA je crois) belge et française, notamment.
    Ma question donc : cela est-il rendu générique ou adaptable "facilement" à d'autres pays ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.