Presque un an jour pour jour après avoir clôturé un deuxième tour de table pour Odoo (ex-OpenERP, Anthony Lesuisse et Fabien Pinckears viennent d’annoncer officiellement qu’Odoo rejoindra Compière et OpenBravo au rang des logiciels de gestion ne proposant qu’un nombre limité de composants libres, honeypot permettant de vendre des modules premiums. C’est une des suites logiques du changement de licence annoncé en février (AGPL copyleft vers LGPL non copyleft).

J’avoue être complètement dégoutté. Mes réactions à chaud sur Twitter et la mailling list.

La communauté ne changera pas de licence : une licence non copyleft mettrait en danger des années de travail. Il ne sera donc plus possible d’installer des modules communautaires en AGPL et des modules « premiums » propriétaires sur la même instance. Modules propriétaires qui porteront probablement 90% de la valeur ajouté à partir de la version 10… Peut-être que l’OCA forkera d’ici quelques mois/années, comme Tryton en 2008… et quand bien même. SAP et Microsoft auront gagner : diviser pour mieux régner.

Comme le dit Raphaël Valyi, un vieux de la vieille en ce qui concerne OpenERP, ce énième changement de modèle économique donne bénédiction à tous ceux qui ont violé la licence AGPL depuis des années et n’ont jamais contribué à la communauté. Les parasites d’hier deviennent les modèles d’aujourd’hui alors que les contributeurs les plus actifs sont durement et durablement punis. On avait déjà eu un aperçu du peu de considération d’OpenERP SA envers sa communauté lors du feuilleton accompagnant la release de la v7, l’abandon très rapide du templating mako ou le renommage marketeux vomitif des Odoo Community Days en Odoo Experience… mais là c’est la totale.

On est loin de ce que nous vendait Fabien depuis dix ans : ci-dessous lors d’une présentation en 2011 ou encore dans ce billet datant de 2013. Et à voir le résultat de Compière et OpenBravo… j’ai pas l’impression que ça soit de bonne augure, sauf peut-être pour les détenteurs du capital à vision court-termiste.

Oui une entreprise doit gagner de l’argent… mais les moyens pour y arriver sont nombreux.

MAJ : d’après Fabien, les entités entrée au capital l’an dernier doivent garder leurs parts huit ans, ce qui peut semble à première vue moins court-termiste que je ne pensais

Je viens de publier sur Pipy une pré-version d’une bibliothèque Python que j’ai commencé il y a un an et demie. C’était ma première fois. Je pense qu’il y a encore pas mal de choses à ajuster dans le packaging et a minima la liste des dépendances.

Hasard du calendrier, je viens de retomber sur le mail d’inscription à QualifEbics,  qui est daté du 30 avril 2011 : presque 5 ans jour pour jour ! Ce serveur de qualification est gracieusement mis à disposition par Valerian (groupe Elcimaï) et je les en remercie.

Que fait-elle ?

Je sais que ce n’est pas très sexy mais ebicsPy permet d’implémenter facilement un client pour le protocole de communication bancaire EBICS. Il permet basiquement de recevoir les fichiers de relevés de comptes et d’envoyer les fichiers de virement.

Pour les plus anciens, c’est EBICS qui remplace ETEBAC3 et ETEBAC5 depuis la fermeture du réseau Transpac par feu France Telecom et la disparition du protocole X25. Désormais le transport de ces fichiers est assuré par le réseau internet (HTTPS/TCP/IP). Leur confidentialité et leur intégrité sont protégés par EBICS qui met en oeuvre une infrastructure de chiffrement et de signature à clés publiques (PKI en abrégé).

Où la trouver ?

Comme indiqué dans le titre, le package est disponible sur Pipy, le dépôt standard des bibliothèques Python. Vous pouvez télécharger l’archive ou utiliser des outils comme pip ou setuptools pour l’installer sur votre machine.

Je ne sais pas si j’aurai le courage de mettre à jour le package à chaque modification du code. Aussi vous pourrez trouver la version la plus à jour sur mon dépôt Launchpad. Là aussi vous pouvez télécharger l’archive ou utiliser Bazar pour cloner la branche. Je pense que je migrerai le dépôt sur Github un jour…

Qu’en faire ?

Comme toute bibliothèque, elle permet au développeur de créer des fonctionnalités le plus simplement possible. En l’espèce, ebicsPy peut aider à développer :

• un script simple peu user-friendly mais redoutablement efficace
• une IHM graphique sous semie-graphique
• un outils appelable en ligne de commande par n’importe quel programme tiers
• un serveur REST ou XMLRPC appelable par n’importe quel programme distant
• un module EBICS pour n’importe quel outil de gestion d’entreprise codé en Python

J’ai choisi de concrétiser cette dernière possibilité en développant un module pour l’outil de gestion d’entreprise libre Odoo (ex-OpenERP). Il n’est pas encore packagé sur l’AppStore Odoo mais les sources sont disponibles sur mon dépôt Github.

C’est utilisable mais il y a encore un peu de boulot pour rendre le code plus présentable. Je pense qu’on pourra très bientôt utiliser EBICS directement dans Odoo :-).

Pourquoi avoir passé autant de temps là dessus ?

• Pour tromper l’ennuie durant mon second semestre en Espagne
• Pour apporter à Odoo une fonctionnalité sympa
• Pour devenir (j’ai encore du boulot XD) un point de référence sur un domaine fonctionnel Odoo
• Pour améliorer ma façon de coder en Python tout en faisant quelque chose d’utile et structuré
• Peut-être un jour le vendre sur l’AppStore Odoo(double licence AGPL et LGPL ?) et gagner une pièce si ce que j’ai développé est utile. Le risque de la LGPL est de voir mon travail intégré dans un programme propriétaire sans mon accord… C’est ça ou empêcher mes potentiels clients d’utiliser les modules propriétaires sexy présents sur l’AppStore… question très difficile.

J’ai eu le plaisir d’être accueilli dans les locaux lyonnais d’Akretion du 7 au 10 juillet pour développer deux briques communautaires du module Point Of Sale d’Odoo(ex-OpenERP) :

• la gestion des afficheurs clients LED (typiquement deux lignes de vingt caractères)
• l’envoi du montant au lecteur de carte bancaire ou éventuellement à l’imprimante de chèques (protocole CONCERT)

Chaque fonction est intégrée via deux modules distincts : l’un modifie le serveur OpenERP et le front-end Javascript du POS et l’autre joue le rôle de driver au sein du proxy hardware développé par OpenERP SA embarqué dans la POSbox. L’ensemble du code est actuellement disponible sur Launchpad et devrait bientôt être mergé dans un projet de l’OCA sur Github.

Au cours de ce code sprint j’ai également commencé à développer un module pos_payment_method_option permettant:

• de spécifier dans l’objet account.journal si l’utilisation de cette méthode de paiement doit déclencher l’ouverture du tiroir caisse
• spécifier dans account.journal si le restant dû doit être saisi automatiquement
• spécifier dans account.journal si la vente doit être validée automatiquement (éviter l’écran de rendu monnaie)
• afficher les boutons correspondant aux méthodes de paiement sur deux colonnes

Bien qu’il reste encore pas mal de choses à peaufiner dans les modules front-end que j’ai écrits, cela ne m’a pas empêché de rêver aux extensions possible du POS.

Les modules suivants devraient être disponibles dans les Addons officiels en v8 :

• menu de sélection du client
• gestion des tables
• gestion des imprimantes ticket coté cuisines
• gestion des promotions et de la fidélité

Ces modules représentent une grosse avancée mais comme toujours, certaines fonctions pourraient être ajoutées :

• la segmentation des tickets par vendeurs avec un code, un code-barres ou une clé Dallas personnelle
• la synchronisation des tickets en cours pour chaque vendeur sur toutes les caisses
• le partage d’un périphérique (le lecteur de CB par exemple) entre plusieurs caisses alors que cette caisse possède sa propre POSbox pour l’afficheur client et l’imprimante tickets. Cela implique la connexion à plusieurs POSbox pour chaque caisse et le routage des flux au sein du proxy.
• l’accès au backend en mode ResponsiveDesign afin de pouvoir saisir un nouveau client ou une nouvelle commande aisément depuis un écran tactile sans devoir recréer des vues spécifiques
• gestion de la réservation des tables de restaurant
• gestion des formules : une ligne d’en tête portant le prix et des lignes filles portant les composants à déstocker parmi un choix restreint. La détection automatique des formules à partir des éléments serait aussi un plus mais pourrait se frotter à une explosion combinatoire
• le changement de méthodes de règlement à posteriori (avant la clôture de la session)
• la réimpression de tickets à posteriori
• pour les commerçants qui souhaitent utiliser l’écran de rendu monnaie, ajouter un bouton avec image pour chaque billet ou pièce possible permettant d’incrémenter le paiement en cash
• la clôture « en aveugle » de la caisse (en option) : le responsable clôture la caisse sans avoir accès au chiffre d’affaire théorique ni au fond de caisse qui en découle. Cette technique est parfois utilisée pour détecter les vendeurs faisant trop d’erreurs ou essayant de taper dans la caisse
• imprimer les tickets à la demande. Notez que s’il on choisit de valider automatiquement une vente dès l’appuie sur le bouton « Cash », il faudra soit prévoir de stocker le ticket précédent (sérialisé pour l’impression) dans un PosModel.last_order_xml soit prévoir un bouton permettant l’impression du ticket pour la vente en cours lors de sa validation
• gestion plus fine des droits coté client : un manager doit rentrer son code pour supprimer un ticket ou une ligne, modifier un prix, mettre une quantité négative ou saisir un rabais manuellement

Comme l’a suggéré Anthony Lesuisse (CTO d’OpenERP SA) sur Twitter, il serait aussi intéressant de développer un afficheur client à base d’écran LCD classique branché en HDMI sur la POSbox. Cela serait plus gourmand en énergie et en place sur le comptoir mais ça apporterait un confort visuel et une grande souplesse. L’on pourrait pousser le concept jusqu’à intégrer des publicités du commerçant ou bien de tiers. L’afficheur client deviendrait une source de revenu complémentaire en transformant le commerçant en une régie publicitaire. Les annonceurs pourraient même associer leur annonce à des produits vendus avec un système d’enchères comme le fait GoogleAdds… C’est beau de rêver.

Ça fait un an, presque jour pour jour que j’ai commencé un projet OpenERP pour une boulangerie. Le but était d’approfondir ma connaissance d’OpenERP tout en travaillant au contact d’une petite entreprise de proximité.

Actuellement trois logiciels sont utilisés : un logiciel de gestion de commandes qui n’est plus maintenu, un logiciel de caisse et son pendant back-office. L’idée était de retrouver dans un seul environnement toutes les fonctionnalités (et les données !) utilisées jusqu’alors en y ajoutant quelques fonctions. Le point important étant d’étendre l’informatisation de l’entreprise, jusque là cantonnée à la caisse et la prise de commandes clients, à la gestion des stocks et de la production(avec prédiction des quantités à produire selon l’historique).

La première réunion a permis de dresser les grandes lignes du cahier des charges et de préciser que pour éviter tout problème(dérive du projet, difficulté de maintenance par un tiers…) on limiterait les développements spécifiques. Quelle belle intention…

Avant de toucher à la partie « production », il fallait ré-implémenter les deux grosses fonctionnalités de caisse déjà présentes sur le logiciel historique et absentes sur OpenERP :

• synchronisation de la vente en cours des vendeurs d’une caisse à l’autre
• la gestion des titres restaurants et des tickets d’avoir correspondants

J’ai donc commencé par prendre en mains l’API javascript d’OpenERP pour surcharger le module de point de vente. Consciencieux, je multiplie les modules afin d’obtenir un ensemble de fonctionnalités réutilisables par la communauté. Au bout de quelques semaines de développements, les tests sur le matériel cible sont très inquiétants : les machines sont âgées et le processeur ne suit pas. Après l’achat d’un serveur, d’un onduleur et d’équipements réseaux il m’était difficile de demander à changer ces PC tactiles (monoblocs !). C’est la panique : en trois jours, je suis obligé de re-développer un front-end de caisse complet avec une libraire graphique python (WXPython). Heureusement, tous est publié en XMLRPC nativement dans OpenERP(même les rapports) donc l’interopérabilité est maximale. Le temps pressant, mon code OpenERP est de moins en moins modulaire… De l’ultra spécifique donc. Impossible à réutiliser ailleurs, beaucoup moins propre et difficile à maintenir par quelqu’un d’autre que moi. Tout ce que je voulais éviter.

Il est maintenant évident que le projet va se prolonger au delà de l’été comme c’était prévu, d’autant plus que le cahier des charge à tendance à augmenter au fur et à mesure que les développements avancent. Je me retrouve à poursuivre le développement à distance, en parallèle de mes études. En octobre premier coup de théâtre : l’entreprise à été démarchée par un entrepreneur du coin qui propose un logiciel dédié à la production en boulangerie… mais qui ne fait pas de caisse. Il est proposé de créer une interface avec le logiciel de caisse historique. Vu le prix demandé et l’incertitude de cette interface, la patronne m’assure que l’on continue le projet : on démarrera les tests en janvier afin d’éviter d’essuyer les plâtres avant Noël.

J’ai donc continué à intégrer toujours plus de fonctionnalités selon le temps dont je disposais. Les fonctions de caisse terminées je pouvais enfin attaquer la prévision des ventes pour l’interface de production. Nous faisons un point fin décembre : l’interface de production possède les fonctions voulues mais le design est trop sobre : les listes ne seront jamais remplies par les  employés. Le design de l’écran de caisse est aussi à reprendre. Il faudrait également que je fasse de la saisie car c’est trop chronophage pour la patronne.

Je commence donc à m’atteler à la tâche en début d’année. Subitement, en février, je n’ai plus de réponse à mes emails. La raison : des employés en arrêts de travail  ralentissent le projet. Mais oui, le projet continue bien.

Tout ça pour apprendre aujourd’hui que le projet s’arrête car un consultant de la chambre des métier leur a fait découvrir de nombreuses possibilités … cachées dans le logiciel de gestion historique. Je suppose que d’autre part, ne pas pouvoir m’engager sur des prestations de maintenance sur le long terme effraie.

Bilan : j’ai passé beaucoup de temps à développer quelque chose qui n’est pas réutilisable et ne servira jamais. Je ne regrette pas d’avoir accepté le projet car j’ai beaucoup appris, techniquement et humainement mais ça n’en est pas moins frustrant. Ce qui m’a le plus plu c’est cette interaction avec l’entreprise : il faut se mettre dans leur peau pour comprendre leur méthode de travail et leurs besoins. On apprend beaucoup de chose sur le métier. C’est bien plus intéressant que de développer dans son coin un programme purement technique, comme j’ai pu l’expérimenter lors de mon stage au ministère de la défense.

OpenERPv8 devrait être publié dans les semaines à venir, en tous cas avant les Community Days de juin. Cette version apporterait d’importantes évolutions du framework demandées par la communauté depuis longtemps :

• nouvelle API et méthodes d’ORM pythonic(décorateurs…)
• moins de conflits dans les OnChange lors de surcharges par plusieurs modules
• un nouveau moteur de rapport gérant l’héritage

En dehors du framework, la gestion des stocks a été totalement refondue afin d’être scalable et de pouvoir s’adapter à des entreprises de tailles différentes. La grande nouveauté marketing mise en avant par OpenERP SA est le CMS très clic-clic permettant de créer des modules de blogs, ou de boutiques en ligne. Voilà pour les nouveautés principales de la v8.

Comme toujours, je ne peux pas m’empêcher de me poser la question : que nous réserve la version suivante, la v9 ? Les grandes lignes devraient être annoncées par Fabien lors des Community Days mais les listes de diffusion laissent présager les points suivants :

• une refonte du module de MRP (l’accompagner d’un module nouveau module de prévisions de ventes ferait sens selon moi)
• un travail sur la sécurité, certains acteurs craignent d’utiliser OpenERP comme e-boutique pour des raisons de sécurité. Il faudra donc ou l’améliorer, ou faire de la pédagogie pour montrer que la sécu est déjà béton. De plus, certains réclament une plus fine granularité des ACL
• une amplification du syndrome revendiqué et assumé NIH : réinvention d’autres outils collaboratifs de l’entreprise (gestionnaire de notes, pads et feuilles de calculs partagés ? …)
• amélioration du « client mail » pour lui apporter les fonctions basiques de l’email qui lui manquent. Je ne suis pas certain qu’utiliser OpenERP comme webmail soit une bonne idée ; mais c’était l’idée de départ
• un version ResponsiveDesign du client web officiel. Cela apporterait un usage natif des différents supports pour tout module. Anecdotiquement, cela permettrait d’avoir une interface plus adaptée lors de l’usage du module POS. Appeler la vue standard d’ajout de contacts en passant une résolution « tablette » dans le contexte serait bien plus ergonomique pour créer de nouveaux clients à la volée depuis le POS sur une dalle tactile.

Un gros morceau serait aussi de préparer OpenERP à passer sous Python 3.x. Je ne sais pas du tout ce qu’il se passe de ce coté là.

Fabien a également annoncé assigner une dizaine de personnes à une nouvelle équipe de marketing. Cette équipe pourrait être en charge de la traduction de la documentation ou bien de la création de vidéos et autres tutoriels. Une future inclusion de ces tutoriels directement dans le client pourrait être envisageable. Certains intégrateurs espèrent que l’éditeur augmente sa capacité à traiter les rapports de bugs qu’ils remontent.

Par ailleurs, on regrettera l’abandon de la part de l’éditeur de modules implémentant des protocoles standards, normalisés, ouverts et répandus tels que CardDAV alors que dans le même temps, OpenERP SA choisit de développer des interfaces pour un unique fournisseur de services : Google.

Je pense qu’à un moment où un autre, OpenERP SA devra contractualiser avec des intégrateurs nationaux pour approfondir et maintenir les modules locaux. En France, de plus en plus d’obligations légales pèsent sur les logiciels permettant de gérer la comptabilité des entreprises. Nouvellement un format d’export des écritures a été imposé par le législateur. Il ne paraît pas très sérieux, pas très vendeur, pour OpenERP de laisser cette fonctionnalité dans un module communautaire. Il n’est pas non plus facilement envisageable de centraliser et de maintenir tous ces développements au sein d’OpenERP SA (la norme d’export DES/DEB vers les douanes en est l’exemple). Sous traiter avec des experts locaux me paraît donc le plus simple.

MAJ du 31/03/2014  : l’hypothétique refonte du module MRP par OpenERP SA dans la v9 est une rumeur infondée. En revanche l’OCA devrait travailler sur cette problématique.