Quoi de plus pour OpenERPv9 ?

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.

De l’importance de 2D-DOC

Les pouvoirs publics font de la dématérialisation un des fers de lance de la modernisation du pays, et ils ont bien raison. En permettant aux citoyens, entreprises et agents publics de ne plus utiliser de papier, on peut potentiellement dégager du temps et de l’argent pour ceux qui ont le plus besoin d’attention.

La difficulté réside pour le moment dans la fourniture de pièces justificatives. Trois solutions s’offrent classiquement :

  • transmettre les pièces justificatives au format papier en joignant un récépissé contenant le numéro de la procédure commencée en ligne
  • demander à l’utilisateur scanner les pièces ou de fournir des documents déjà disponibles au format électronique (factures par exemple) et joindre au dossier en ligne
  • mettre en place un système de transmission des pièces entre les différentes institutions produisant les pièces et l’administration destinatrice

Les deux premières solutions le document est non-structuré. Cela impose une validation manuelle des pièces par un agent ; il n’est donc pas question d’instruire automatiquement le dossier. La troisième solution impose de mettre en place des normes et des dispositifs lourds dans un nombre pré-défini d’institutions. D’autre part, dans un contexte de méfiance face aux interconnexions abusives de données des gouvernements, une part croissante de la population renoue avec les inquiétudes nées du projet Safari(provoquant la création de la CNIL) dans les années 1970.

Une alternative très intéressante réside dans la norme ouverte 2D-DOC (créée par la société AriadNEXT puis publiée sur le site de l’ANTS). L’idée consiste à inclure un code-barre 2D (au format data-matrix) sur les documents récapitulant les données du document et contenant le hash de la signature électronique de l’entité émettrice. Ainsi, l’on dispose d’une sécurisation électronique transposable sur support papier. Contrairement à des fichiers structurés signés électroniquement (factures EDIFACT ou ebXML par exmple), le contenu reste toujours « human readable ». Les personnes technophobes pourraient instruire leur dossier avec une facture d’électricité papier (pièce déjà scannée par les services courrier) et les plus technophiles directement avec une facture PDF de leur opérateur télécom par exemple. Cela permet donc de passer progressivement vers une instruction automatisée des dossiers administratifs dans les cas relativement standards. On limite ainsi tout risque d’amplification de la fracture générationnelle ou numérique. Pourrait-on imaginer à terme une instructions totalement automatique de 80% des dossiers de bourse CROUS par exemple ?

L’autre avantage indéniable est la non centralisation du processus. La mise en place de la transmission des actes d’états civil par COMEDEC est une démarche lourde : écrire une norme spécifique au besoin, créer une plateforme centrale, signer des conventions avec les mairies et les notaires… Ce genre de démarche se justifie probablement pour des choses hautement sensibles et régaliennes comme l’état civil mais parait difficilement généralisable pour des justificatifs de domicile par exemple. Là est toute la beauté de 2D-DOC. Le contexte politique est à un troisième acte de décentralisation. Les collectivités territoriales auront donc probablement de plus en plus de procédures propres. L’ouverture et la souplesse de 2D-DOC permet à toute structure de se lancer dans la dématérialisation à son rythme… tout en repoussant la menace de Big-brother. Les structures les plus innovantes montreront la voie aux autres. Rien n’empêche à posteriori de créer des plateforme type COMEDEC pour des besoins spécifiques ou des démarche très pénibles pour les citoyens. Entre temps, administrations (et entreprises !) et utilisateurs auront gagné du temps et de l’argent.

Techniquement deux petits détails me dérangent dans 2D-DOC :

  • la taille d’un code barre étant limitées, les certificats électroniques (la clé publique permettant de vérifier l’authenticité d’une signature) sont déportés sur internet. Cependant, ceux-ci semblent actuellement disponible dans un répertoire centralisé. La résilience est donc limitée.
  • la liste des documents « encodables » est ancrée en dur dans la norme. Ajouter un nouveau type de document (attestation d’assurance responsabilité civile par exemple) nécessite donc de réunir un nouveau comité de normalisation et de repasser toutes les étapes de validation. Un champ permettant d’indiquer l’URL d’extensions pourrait assouplir la norme.

Avec le déploiement de projets comme COMEDEC, ACTES, HELIOS ou CASSIOPEE, les agents publics disposeront tous bientôt d’une carte professionnelle contenant un certificat 3 étoiles conforme au RGS permettant de signer électroniquement un document avec une valeur légale identique à la signature manuscrite. Les faibles pré-requis d’infrastructure pour généraliser 2D-DOC sont donc réunis.

Outre l’ajout d’un champ contenant une URL d’extension de la norme, l’enrichissement de celle-ci devrait rapidement porter sur les documents suivants, couramment demandés :

  • certificats de scolarité
  • attestation d’assurance (au moins habitation, responsabilité civile et auto/moto)
  • certificats médicaux d’aptitude
  • prescriptions médicales (doublon avec le projet de dématérialisation des ordonnances de l’ordre des pharmaciens ?)

Ajouter le support de 2D-DOC aux factures acceptées sur Chorus-factures ferait également sens.

La dernière chose pour permettre aux collectivités de commencer à utiliser 2D-DOC serait de modifier par la voie règlementaire (ordonnance, décret…) ou à défaut législative(peut-être dans le PLF 2015) les codes régissant les grands secteurs règlementés produisant ces pièces justificatives (compagnies d’assurance, de télécom, distributeurs d’électricité ou de gaz, établissement scolaire…) pour les obliger à inclure 2D-DOC dans leur chaîne d’éditique. Les modifications étant raisonnables, on pourrait imaginer une entrée en vigueur très rapide à l’échelle de l’administration, d’ici 12 ou 24 mois. Ensuite, à chacun d’utiliser ou non la capacité de vérification automatique de ces documents dans ce nouveau cadre d’innovation ouverte.

PopcornTime : une piste d’archi pour Netflix ?

Outre la vente de SFR, cette semaine a été marquée par de très nombreux articles sur PopcornTime. Je l’ai testé en début de semaine et je dois avouer que c’est bluffant. C’est ce qu’on peut appeler du design, au sens anglo-saxon du terme : ce n’est pas seulement « beau » c’est surtout très pratique, très fonctionnel.

L’idée principale est de mettre à disposition des flux torrents en streaming au sein d’une interface ultra-simple permettant d’accéder aux résumés de films et aux sous-titres. Cela offre un accès immédiat aux films disponibles en torrents pour toute madame Michu anglophile.

Évidement, le droit d’auteur s’applique sur les flux que l’on télécharge. Selon les films et la localisation géographique il est donc possible que l’utilisateur se mette dans l’illégalité. Les majors faisant pression sur l’équipe ayant développé ce projet à titre totalement gracieux, ceux-ci ont choisi d’arrêter le projet(bien qu’ils ne faisaient absolument rien d’illégal). Le code, open-source, étant disponible sur Github, il va probablement être rapidement forké.

Ce qui est intéressant c’est l’architecture sous-jacente du système. Comme tout Torrent, lorsqu’un peer télécharge un ficher, il seed également. C’est à dire qu’il envoie à son tour ce fichiers à ceux qui le demandent. Plus il y a de personnes qui regardent un film, plus celui-ci est disponible rapidement. On ne divise donc pas une bande passante disponible vers un serveur unicast (comme Youtube). Cela s’apparente plus à la multiplication des pains.

Ces derniers jours on a beaucoup parlé de Netflix qui tenterait de s’installer en France d’ici l’automne. Netflix voulant diffuser ses programmes en 4K (« ultra HD »), cela pose de gros problèmes de transit car tous ses serveurs sont centralisés aux États-Unis. Il y a donc une asymétrie des volume lors de l’interco avec les FAI européens (au travers de Tiers1 comme Cogent) ce qui pose des problèmes de gros-sous(pouvant déboucher sur la non neutralité du réseau). Internet pour rappel, n’est pas fait pour avoir des échanges aussi déséquilibrés mais au contraire pour répartir le contenu et distribuer la charge.

Ne pourrait-on pas imaginer que Netflix s’inspire de l’architecture Torrent pour éviter ces problèmes d’engorgement ? Tout ça avec les DRM(verrous numériques non interopérables dignes d’un autre âge) qui vont bien pour faire plaisir aux majors bien entendu. Cela me parait économiquement, concurrentiellement et technologiquement bien plus sain que de recourir à des CDN.

L’ONP, c’est terminé.

Le gouvernement, sur conseil de la DISIC, vient d’acter l' »abandon » du projet d’opérateur national de paie (plus de détails ici).

Actuellement les fonctionnaires sont payés par transfert de fichiers de paie entre les ministères (et services décentralisés) et les SLR (services liaisons-rémunérations) locaux de la DGFiP. À la DGFiP c’est l’application PAY qui assure depuis 40 ans le traitement de ces fichiers et l’envoi des ordres de virement. Les technologies supportant PAY n’étant plus maintenues et l’architecture de celle-ci étant obsolète, ONP ou pas il va bien falloir la remplacer.

Quelques caractéristiques un peu particulières du système actuel auxquelles devait remédier le SI de l’ONP :

  • la paye du mois précédent est prise par défaut. Ne pas apparaitre dans le fichier de mouvements équivaut à être payés comme la paie précédente
  • les fichiers ministériels envoyés avant le 20 du mois n correspondent à la paie qui sera versée à la fin du mois n+1
  • le ministère de la fonction publique ne dispose d’aucun info-centre précis sur sa masse salariale (concernant les trois fonctions publiques)

Outre le remplacement de cette application cruciale en fin de vie,  le projet ONP ciblait de nombreuses avancées. Il prévoyait une normalisation des processus de paie sans pour autant contraindre de trop les ministères : ceux-ci concevait un SIRH indépendant mais fortement interfacé (au travers du noyau FPE). Ainsi lorsque les SIRH actuels transferts des sommes à PAY, seuls des évènements de gestion (naissance d’un enfant, changement d’échelon…) auraient été transférés entre le SIRH est l’ONP. D’autre part, et au moins aussi important, l’organisation des services de paies évoluait en voyant la création de services spécialisés (un peu comme les services facturiers mis en place dans la foulée de Chorus) : les PESE (pôles d’expertise et de services). Il était donc prévu une mise en place de « bonnes pratiques » au niveau organisationnel ; ce qui fait le plus souvent défaut aux projets informatiques (comme Louvois et le programme SOURCE).

Si l’arrêt de ce chantier peut nous éviter une dérive budgétaire énorme ou des problèmes de rémunération comme Louvois pourquoi pas. Cependant il est à nuancer car les paies des militaires paraissent bien plus complexes que celles des fonctionnaires non-militaires. D’autre part, les statistiques officielles du mastodonte Chorus nous indiquent si le dépassement initial du budget a été conséquent, les coûts de maintenance annuels sont en dessous des prévisions. D’un point de vu budgétaire maintenir PAY en fonctionnement est également coûteux voire techniquement dangereux.

D’autre part, des dizaines de projets gravitent autour du raccordement à l’ONP(via l’intégration du référentiel de paie de l’État, le noyau FPE). Les crédits déjà consommés purement et simplement jetés à la poubelle sont donc plus important qu’annoncés. Dans le contexte politique actuel, on peut également douter de l’opportunisme de l’exécutif face à l’engagement de trouver 50 milliards d’économies dans les prochaines années… économies qui devaient être au départ structurelles et non conjoncturelles ou contre l’investissement.

Va-t-on jeter le bébé avec l’eau du bain : la réorganisation des services, l’urbanisation des SI ministériels (et des opérateurs prévus en paye à façon) ?

Louvois, SI paye, la prochaine victime ne serait-elle pas SIRHEN ? L’audit du cabinet Neoxia/Deloitte met en effet à l’épreuve ce programme du secrétariat général de l’éducation (MEN, MESR…) sur 2014. Les projets RH semblent confrontés à la complexité incommensurable des systèmes de paie des agents publics. Une réforme structurelle profonde de la fonction publique (la fusion en corps interministériels par exemple) semble un prérequis au prochain changement de système ; dans une vingtaine d’années. À noter que la simplification du système de primes et leur moindre recourt serait aussi bénéfique pour rendre comparables les systèmes de retraite privé/public et réformer de manière égalitaire et juste.

Je suis curieux de voir comment va évoluer la situation car quoiqu’il en soit… PAY doit mourir.

MAJ : une version isofonctionnelle de PAY en Java serait à priori re-développée en interne à la DGFiP (détails).

MAJ du 7 avril 2014 : quelques précisions sur les points développé si dessus début mars dans l’article de silicon.fr du 4 avril 2014

MAJ du 24 avril : le rapport du directeur de la DISIC ayant mené à la fin du programme est disponible Rapport-jmarzin-pdf

MAJ du 22 mai : un nouveau décompte incluant les SIRH ministériels. Il est malgré tout impossible de connaître le surcoût induit par l’intégration du noyau FPE lors de leur refonte, nécessaire en soit. Article du silicon.fr du 21 mai 2014

Libon, enfin un début de quelque chose interopérable.

La semaine dernière Orange publiait ce communiqué, à propos de sa messagerie OTT. Je suis habituellement très critique envers Orange. Pour une fois c’est le moins arriéré des opérateurs mobiles grand-public français.

Les smartphones ont commencé à réellement se démocratiser depuis 2010 environ. En France, ce mouvement s’est accompagné des forfaits avec SMS illimités et un début de forfaits data 3G. Les opérateurs en place tout comme Free ont cependant voulu s’accrocher désespérément à leurs marges sans voire qu’avec ou sans eux, les utilisateurs, de plus en plus mobiles, passeraient à un mode de communication tout IP. Des problèmes de qualité de service rendent la chose légèrement plus délicate pour des communications vocales, mais pour des mini-message c’est techniquement très aisé.

Bilan des courses :

  • les opérateurs européens ont pu grappiller quelques euros d’itinérance SMS/MMS à l’étranger durant quatre ans de plus
  • Whatsapp est devenu leader, maintenant racheté par un géant américain
  • de nombreuses personnes ont perdu toute confidentialité dans leurs échanges, c’est particulièrement vrai en Espagne

N’aurait-il pas été plus efficace d’attribuer un compte XMMP du style numero_tel@xmpp.opérateur.fr à chaque nouvel utilisateur depuis le début de l’expansion des smartphone et de conseiller d’utiliser ce compte avec des clients mobiles en voyage ? N’aurai-t-il pas été possible d’utiliser la norme ENUM dans le DNS (comme expliqué dans mon premier article) contenant l’URL du compte XMPP associé à un numéro de téléphone ? Ce qui aurait permis de choisir librement un fournisseur de confiance pour recevoir ses message de manière transparente pour l’utilisateur ? Pourrait-on imaginer d’avoir un serveur sur son téléphone (nécessite l’IPv6) afin d’assurer que nos communications soient chiffrées directement à la source ?

Je n’ai pas encore creusé le fonctionnement de Libon. Il reposerait a priori sur une norme OpenChat apparemment dérivée d’XMPP (d’après http://blog.libon.com/status/)  et un client HTML5 serait disponible pour tous ceux ne voulant pas installer d’application. Très bien ; mais la chose la plus importante est l’interopérabilité d’infrastructure : celle de Libon me permettra-t-elle d’héberger mon propre serveur de messagerie, ou bien d’héberger mon compte chez un ami, une association ou une petite entreprise à qui je fais plus confiance que mon opérateur national ? OpenChat apporte-t-elle réellement une amélioration technique ou cette norme maison a-t-elle pour but une nouvelle fois de nous enfermer dans un éco-système ? Parle-t-on d’une extension d’XMPP qui sera documentée (comme Jingle pour la vidéo) ou bien fermée comme Whatsapp ?

Quand est-ce que les opérateurs montreront qu’ils ont compris qu’un abonnement mobile est sensiblement similaire à un abonnement fixe : on loue une connexion IP (neutre, supportant l’IPv6 si possible) a un prix mensuel fixe (la plupart du temps). La seule différence est que cette connexion IP est disponible sur tout le territoire national et peut éventuellement entraîner des frais de roaming à l’étranger. Les autres services IP (appels, SMS, TV, jeux, ristourne pour des services tiers) peuvent éventuellement augmenter le ticket moyen… mais sont périphériques.

Quand est-ce qu’ils comprendront que la mentalité « telecom » est mourante sur le marché grand-public ? L’un d’eux osera-t-il un jour innover et devancer le marché plutôt que de suivre le monde internet voire reculer pour mieux sauter ?

Je ne suis d’ordinaire pas interventionniste, mais quand on voit le risque de perte d’interopérabilité et confidentialité de nos moyens de communications, j’en viens à me demander si une régulation en la matière ne serait pas nécessaire. On ne parle pas de n’importe quel service marchand, mais d’échanges interpersonnels. Le passage à l’IP devrait, de part la nature décentralisée de l’architecture d’internet, nous libérer de l’emprise des 4 grands opérateurs nationaux et non pas concentrer le pouvoir dans un ou deux géants mondiaux.