Auteur/autrice : yuntux

Un chat intégré dans Zimbra 8.6

MAJ du 30/07/2016 : Ce tutoriel se fonde sur ejabberd 16.01 et une Ubuntu 16.04 LTS. Il a été testé sur la version 8.7 de Zimbra (sortie le 15/07/2016).

Depuis sa version 7.x, Zimbra n’a plus de module de chat natif. Cette fonctionnalité devrait revenir en deux temps :

1- intégration d’un client XMPP dans le client web de Zimbra 8.7 -> nécessitera un serveur externe
2- ré-internalisation d’un serveur XMPP dans Zimbra pour la version 8.8

Je vous propose ici d’intégrer un système de chat externe (client web et serveur) dans Zimbra 8.6. Le serveur pourra notamment être réutilisé lors de la migration à Zimbra 8.7.

Choix du client Javascript

Je comptais au départ intégrer le client XMPP javascript JSXC car outre le chat textuel, il propose de la visio one2one directement via son navigateur sans plugin (protocole WebRTC). Cependant j’ai choisi de poursuivre le travail d’intégration de Converse.js de Barry de Graaff et d’intégrer l’authentification Zimbra.

Contrairement à JSXC, Converse.js ne gère pas la visio. Cependant rien ne laisse entendre que le client officiel qui sera intégré dans de la future version 8.7 offrira ce service. Ce n’est peut-être pas plus mal de ne pas habituer les utilisateurs à ce service loin d’être indispensable. La migration en sera d’autant plus facile.

Comment ça fonctionne ?

  1. Lors de la connexion au client web Zimbra, le zimlet com_zimbra_converse se lance automatiquement.
  2. Le zimlet récupère l’adresse email de l’utilisateur connecté ainsi que le token d’identification. L’email et le token (préfixé avec « zimbra_auth_token++ ») sont passés au client javascript Converse.js.
  3. Ce client envoie alors ces données au serveur ejabberd via le proxy  HTTP Zimbra. Notez qu’il est primordial que l’interface HTTP du serveur d’ejabberd soit chiffrée (HTTPS/TLS) si le serveur ejabberd n’est pas sur la même machine que le serveur Zimbra afin que le token d’authentification Zimbra ne puisse pas être compromis par une attaque man-in-the-middle.
  4. Le serveur ejabberd passe l’email et l’auth token préfixé à un script d’authentification spécifique.
    • Ce script teste la présence de la chaine « zimbra_auth_token++ » en début de token.
    • Si elle est présente : le script vérifie via l’API REST de Zimbra que le token est valide et appartient à un utilisateur qui a le droit d’accéder à la ressource demandée (à l’inbox du compte dans notre cas).
    • Si elle est absente (c’est donc un client XMPP distinct du client web Zimbra qui souhaite se connecter) : le script vérifie que le couple email/password est valide auprès du serveur Zimbra
    • Le script renvoie True ou False au serveur ejabberd selon que le serveur Zimbra ait validé ou non les paramètres transmis

Cette architecture est donc totalement transparente pour l’administrateur système. Il n’est pas nécessaire de créer les comptes sur le serveur ejabberd.

Le Zimlet et le script d’authentification ejabberd sont disponibles sous licence libre sur mon compte Github.

Installer un serveur ejabberd et paramétrer l’authentifieur Zimbra

Installer le serveur :

zimbra@zimbra01 ~ sudo apt-get install ejabberd

Créer le compte admin dans le fichier /etc/ejabberd/ejabberd.yml :
  admin:
     user:
         – « admin »: « localhost »
         – « admin »: « fontaine-consultants.fr »

hosts:
  – « localhost »
  – « fontaine-consultants.fr »

Créer le mot de passe associé :

zimbra@zimbra01 ~ sudo ejabberdctl register admin localhost mon_mot_de_passe

Vérifier que le module de binding HTTP est bien activé dans le fichier /etc/ejabberd/ejabberd.yml :

mod_http_bind: {}

Activer le chiffrement sur le port XMPP 5022 et sur le binding HTTPS

Télécharger le script d’authentification Zimbra et donner les droits associés :

cd /etc/ejabberd/

zimbra@zimbra01 ~ sudo wget https://raw.githubusercontent.com/yuntux/com_zimbra_converse/master/zimbra_auth.py

zimbra@zimbra01 ~ sudo chown ejabberd:ejabberd zimbra_auth.py

Ajouter le script d’authentification Zimbra  dans le fichier /etc/ejabberd/ejabberd.yml :

##
## Authentication using external script
## Make sure the script is executable by ejabberd.
##
auth_method: external
extauth_program: « /etc/ejabberd/zimbra_auth.py »
extauth_cache: 0
extauth_instances: 1

Redémarrer le serveur :

zimbra@zimbra01 ~ sudo service ejabberd restart

Intégrer le Zimlet et paramétrer Zimbra

L’accès au ZM_AUTH_TOKEN n’est pas accessible par la fonction JS document.coockie() dans le Zimlet. Il est nécessaire de passer par une JSP pour récupérer le token d’identification (bizarrement document.cookie ne permet pas d’y accéder coté client).

Dans Zimbra 8.6, les JSP ne sont pas activées par défaut. Il est nécessaire de les activer :

root@zimbra01:~# su – zimbra
zimbra@zimbra01:~$ zmprov gs monserveur.net | grep zimbraZimletJspEnabled
(Nothing showed)
zimbra@zimbra8-dev:~$ zmprov ms monserveur.net zimbraZimletJspEnabled TRUE

Pour des raisons de sécurité, le navigateur bloque l’accès à un autre domaine/port depuis le javascript du client web Zimbra. Il est donc nécessaire de passer par un proxy ancré dans Zimbra pour atteindre le serveur ejabberd depuis le client web Zimbra :

zimbra@zimbra01 ~# nano /opt/zimbra/conf/nginx/templates/nginx.conf.web.https.default.template
*  avant la dernière accolade, ajouter les lignes suivantes :
location /http-bind {
    proxy_pass http://monserveur.net:5280/http-bind/;
}

Télécharger et paramétrer le Zimlet :

zimbra@zimbra01 ~ cd /opt/zimbra/zimlets-deployed

zimbra@zimbra01 ~ mkdir _dev

zimbra@zimbra01 ~ cd dev

Télécharger le dossier (et les fichiers qu’il contient) https://github.com/yuntux/com_zimbra_converse/blob/master/com_zimbra_converse

Remplacer si nécessaire l’URL du binding http vers le serveur ejabberd aux lignes 51 et 57 de converse_zimlet.js

Redémarrer Zimbra :

zimbra@zimbra01:~$ zmcontrol restart

Recharger le client web : le client devrait se connecter au serveur ejabberd automatiquement.

Point sur le chiffrement des communication

Par défaut, ejabberd est configuré pour écouter sur le port 5222 en startTLS. Cela permet de faire un handshake « en claire » puis de passe en mode chiffré si le client et le serveur en sont capables. Le startTLS permet ainsi de gérer des communications chiffrées et non chiffrées sur un même port.

Pour forcer l’usage du chiffrement sur ce port, il est nécessaire de dé-commenter la ligne starttls_required: true correspondant au port 5222. Pour renforcer la sécurité, il est aussi possible de désactiver les version obsolètes de chiffrement via les lignes (    protocol_options:      – « no_sslv3 »      – « no_tlsv1 »).

Si certains clients souhaitent se connecter directement en mode chiffré, sans passer par le hanshake startTLS, vous devez ouvrir un autre port (par exemple le 5223, qui est le port chiffré standard pour XMMPP) en indiquant tsl = true au lieu de starttls=true. Ce port ne sera utilisé que si la case « utiliser SSL est coché sur Apple Message » ou si l’option « Utiliser le SSL ancien style » est sélectionnée sous Pidgin.

Archiver les messages

L’archivage des messages échangés en XMPP peut basiquement être fait par le client. Cependant, si vos utilisateurs sont amenés à se connecter depuis différents clients, ceux-ci ne disposeront que des messages qui leurs auront été destinés (que lorsqu’ils étaient connectés).

Deux normes XMPP existent pour gérer l’archivage : la XEP-0136 et la XEP-0313. La XEP-0136 est plus ancienne est plus complète… mais aussi plus difficile à implémenter. De fait, peu de clients sont compatibles avec cette dernière. La XEP-0313 a été créé pour palier à cette écueil de normalisation. Elle est moins complète mais implémentée par plusieurs clients, dont Converse.JS.

Pour mettre en oeuvre cette fonctionnalité, il est nécessaire d’installer une base de données robuste, a base de donnée livrée avec ejabberd (Mnesia) n’étant pas conçue pour supporter efficacement de gros volumes. Voici comment installer la base Mysql :

  • installer les paquets erlang-p1-mysql et mysql-server
  • créer l’utilisateur Mysql ejabbed : echo « GRANT ALL ON ejabberd.* TO ‘ejabberd’@’localhost’ IDENTIFIED BY ‘password’; » | mysql -h localhost -u root
  • créer la base de données ejabberd : echo « CREATE DATABASE ejabberd; » | mysql -h localhost -u ejabberd -p
  • importer le schéma de base de données :
    • gzip -d /usr/share/doc/ejabberd/examples/mysql.sql.gz
    • mysql -h localhost -D ejabberd -u ejabberd -p < mysql.sql
  • changer les valeurs du fichier /etc/ejabberd/ejabberd.yml
    • sql_type: mysql
    • sql_server: « localhost »
    • sql_database: « ejabberd »
    • sql_username: « ejabberd »
    • sql_password: « password »

On peut dès lors activer le module d’archivage conforme à la XEP-0313. Ajouter les lignes suivante à la section modules :

mod_mam:
db_type: odbc
default: always

Redémarrer ejabberd : service ejabberd restart

Le module d’archivage doit alors être fonctionnel. Les messages sont stockés dans la table « archive » de la base de données.

Prochaines étapes

Actuellement le script d’authentification ejabberd/zimbra appelle l’API de consultation de la boite du calendrier Zimbra avec une amplitude de 0 jours (donc aucun évènement) : https://localhost/home/user@monserveur.net/calendar.atom?start=0days&end=0day

Cela constitue un détournement relativement lourd : on télécharge le calendrier (vide par construction) à chaque chargement du client web Zimbra. Apparemment, il serait possible d’appeler un service GetInfoRequest pour vérifier la validité et le propriétaire du token. De plus dans le cas tordu où Alice aurait volontairement partagé son inbox avec Eve (qui dispose d’un autre compte sur le serveur), Eve pourrait se faire passer pour Alice sur le chat (en utilisant son token avec l’adresse d’Alice). Le pauvre Bob se ferait avoir, une fois de plus. Notons cependant que si Alice a suffisamment confiance en Eve pour partager sa boite de réception email, il est probable qu’elle accepte également que Eve accède à son compte XMPP !

En ce qui concerne le login classique (par client XMPP externe), il est peut-être possible d’appeler le service de login de Zimbra pour déterminer la validité d’un couple user/password sans demander à voir l’inbox (ce qui n’est pas très optimisé).

Remerciements

Je remercie Barry de Graaff pour la version originale de son module com_zimbra_converse. Je remercie également StarXpert qui m’a permis de comprendre qu’il faut passer par une JSP pour obtenir l’auth-token en lisant le code de son module Starxpert Jappix Chat.

État plateforme ≠ base de données unifiée

Au cours de l’appel proposition concernant le projet de loi pour une République numérique, l’Institut Montaigne a formulé la proposition suivante :

Une proposition inadaptée

1- Le SI de l’État, et les SI publics en général, sont par nature distribués. Ils reflètent l’organisation de la sphère publique mais aussi l’historique d’outils de gestion en perpétuelle évolution. Vouloir concentrer les données au sein d’une base unique ne me parait ni réaliste, ni souhaitable. En revanche, maîtriser le caractère distribué du SI est indispensable : cela passe notamment par FranceConnect.

2- Cette centralisation me parait anxiogène ce qui risquerait, de remettre en cause l’édifice proposé (cf affaire Safari en 1974).

3- Cette base unique me parait inutile. L’important pour l’usager est de ne pas avoir à fournir une information déjà connue de l’administration. Cette simplification est déjà au cœur de FranceConnect et ne nécessite pas l’usage d’une base de données centralisatrice unique.

Une perception erronée de FranceConnect et de l’État Plateforme

Contrairement à ce qui est dit en introduction de la proposition de l’Institut, le dispositif FranceConnect n’est pas être un « identifiant unique » ni une identité numérique unique mais un dispositif de fédération d’identités. Il n’induira pas la distribution d’un identifiant unique commun aux administrations utilisatrices (cf décret 2015-254).

D’autre part, FranceConnect permet la transmission d’information entres administrations à l’initiative du citoyen sans qu’aucune donnée ne transite par un quelconque point central (seul le vecteur d’autorisation est géré par le serveur FranceConnect). L’usager maîtrise les autorisations d’accès à ses données, autorisations qui sont historisées. C’est un mélange très pragmatique et équilibré de sécurité informatique a priori (via les protocoles OpenIDConnect et OAuth) et juridique a posteriori (responsabilisation des fournisseurs de données) qui reflète une réflexion d’architecture poussée.

FranceConnect procurera ainsi aux administrations volontaires les moyens de partager facilement de l’information en pleine adéquation avec le principe d’autodétermination informationnelle prôné par l’État plateforme. Cette proposition de l’Institut Montaigne me paraît en décalage total avec la philosophie l’État plateforme : quelque chose de souple, pragmatique et pérenne.

Pourquoi Orange limite « l’innovation »

Un de mes amis a récemment décidé de quitter les USA et de revenir en France pour devenir entrepreneur. Le voilà donc en quête d’une opportunité de profit Schumpetérienne. Il s’applique à trouver une idée sympa à développer s’appuyant sur un modèle d’affaire a priori crédible.

Pouvoir encapaciter (empower) le citoyen numérique

J’ai souvent dit que je ne voulais pas « monter ma start-up » juste par principe ou parce que c’est à la mode mais que si un jour je trouvais un besoin à satisfaire intéressant, je pourrais franchir le pas. Je n’ai pas trouvé de modèle d’affaire miracle mais le besoin est là : livrer clé en main à ceux qui souhaitent reprendre en main leur vie privée numérique un serveur personnel… sur lequel on pourrait aussi héberger ses proches.

Ces dernières années, l’affaire Snowden aidant, de nouvelles briques user-friendly se développent : le RaspberryPi2 pour le matériel, Yunohost pour l’administration système, Let’sEncrypt pour la gestion des certificats,  CaliOpen pour les échanges inter-personnels, Owncloud pour l’intégration de services ou CozyCloud pour la standardisation et l’architecture, Tahoe-LAFS pour la sauvegarde distribuée en P2P, etc. Bon il manque encore des choses, notamment en terme de redondance simple, dynamique et décentralisée mais ça avance.

Cependant, la réservation d’un nom de domaine, la configuration de la zone DNS (ou le paramétrage du GlueRegistry) et le paramétrage en local nécessitent toujours des connaissances avancées et du temps. En dehors de tout support ou toute formation additionnels, ces tâches devraient être automatisées. Bonne nouvelle : moyennant la prise en main de quelques API et beaucoup de travail, c’est possible…

… mais pas chez Orange

Là où ses concurrents proposent de l’IPv4 fixe sur de l’ADSL dégroupée, du reverse DNS, du NAT-Hairpinning/NAT-LoopBack et l’ouverture du port 25… Avec la moitié des parts de marché, le premier vendeur de Minitel haute définition français saperait le projet. À quoi bon proposer une alternative à Gmail si c’est pour passer par un relai SMTP Orange ?

Serait-ce trop demander que cette entreprise, un quart publique, devienne enfin un fournisseur d’accès à internet et fournisse les quelques services techniques qui lui incombent avant de distribuer du contenu et de se sucrer sur le dos de la neutralité des réseaux ? Serait-ce trop complexe de payer un ou deux commerciaux en moins et de faire un portail correct, simple avec les basiques d’un opérateur de réseau ? Avoir de la fibre optique dans mon salon uniquement pour pomper (et se faire pomper le portefeuille) plus vite sur OCS, Deezer et DailyMotion, non merci…

Faites votre boulot : fournissez de l’Internet !

Petit point sur la DSN

C’est fait ! Une première vague d’entreprises et de tiers déclarants a été obligée de déposer pour la première fois une DSN concernant les salaires versés en avril et déclarables au 5 ou au 15 mai.

Cet article fait écho à celui-ci ou encore celui-là.

Sommaire :
Bref historique du projet
Quelles évolutions techniques pour cette norme ?
Vers une évolution structurelle pour la DSN : le transfert du calcul des cotisations
La DSN est un des outils pour construire le système de demain
La simplification du bulletin de paie : un cache-misère contre-productif

Bref historique du projet

Pour rappel, la déclaration sociale nominative est un dispositif visant à simplifier et harmoniser la collecte des données sociales auprès des employeurs. En projet depuis une quinzaine d’années, son point de départ législatif est la loi Warsmann promulguée en mars 2012 et prévoyant sa généralisation au premier janvier 2016 à tous les employeurs de droit privé (procédures alignées des régimes spéciaux comprises).

Sa construction s’est déroulée en trois étapes permettant une augmentation graduelle de la couverture fonctionnelle en phase avec un processus de normalisation regroupant de très nombreux acteurs de la protection sociale en France. On distingue la DSN de la norme NEODeS qui permet son implémentation technique dans les logiciels de paye. Un premier cahier des charges avait été produit à l’été 2012(que j’avais d’ailleurs implémenté dès novembre 2012 sur Odoo, encore nommé à l’époque OpenERP) puis un second portant les informations des DUCS URSSAF en 2013 et enfin un troisième élargissant le dispositifs aux autres DUCS.

La phase trois portant sur ce dernier cahier des charges sera lancée cet été. Nous sommes donc sur la bonne voie. Quelques points restaient encore à éclaircir lors des rencontres éditeurs en début d’année :

  • une question quant à l’impossibilité de renseigner le montant des exonérations (page 6 du compte rendu)
  • un taux d’erreur important lors de la reconstitution du salaire pour le calcul des IJSS (page 88/89 du support)
  • netEntreprise indique que 3% des déclarations ont rencontré des problèmes lors du dépôt de mai 2015

Soulignons également la complétude de la norme qui va jusqu’à prendre en charge avec souplesse la diversité des instituts de prévoyance tiers.

Quelles évolutions techniques pour cette norme ?

Certaines évolutions à moyen termes sont déjà perceptibles :

  • L’intégration de la DPAE (ex-DUE). Dans son rapport annuel 2013, le Comité de normalisation des données sociales propose d’intégrer la DPAE dans un message signalement d’intention d’embauche au sein de la DSN.
  • La Déclaration d’Accident du Travail : il serait logique que les données jusqu’ici fournies par une norme spécifique à la CNAMTS (ou par formulaire papier) soient reprises dans la DSN alors que la subrogation des IJSS en cas d’arrêt maladie est déjà supportée.
  • La prise en charge des nombreuses spécificités du secteur public sont actuellement étudiées par un groupe dédié de la caisse des dépôts (ici ou là). Un récent projet d’ordonnance semble orienter l’intégration de ces populations à horizon 2020. Les récents échecs des programmes RH Louvois, ONP et l’incertitude du programme SIRHEN ne sont probablement étrangers à ce délais particulièrement important.
  • La suppression des codes type personnel : actuellement la DSN reprend les CTP issus de la DUCS URSSAF. Ces agrégats semblent superflus et pourraient être supprimés dans les années à venir. La cohérence technique des données pouvant être assurée plus simplement.
  • La généralisation de l’usage du NIR pour identifier les salariés. Actuellement la norme spécifie pour chaque OPS si un numéro d’identification supplémentaire doit être porté par la norme (ex : donnée S21.G00.81). Par nature le NIR est destiné à la sphère sociale. C’est le rôle de chaque OPS de gérer une table de trans-codage transitoire si elle lui est techniquement indispensable.
  • L’accession gratuite et simple des entreprises à un dispositif de dématérialisation des fiches de payes. Le « coffre-fort électronique » dont parlent de nombreux tiers de confiance commerciaux pourrait facilement être assuré par l’ACOSS. Il ne s’agit après tout que de stocker des PDF (voire des fichiers XML ré-exploitables) et d’en garantir l’intégrité dans le temps…
  • Le passage au format XML : le cahier des charges de la phase 2 a introduit une notation sémantique des champs, les expressions régulières des contrôles reprennent la syntaxe XMLSchema et les fichiers de contrôles comme la structure de la norme sont eux-même en XML. Cela permettrait aux éditeurs de contrôler les fichiers à envoyer en contrôlant directement le respect du schéma XML dans leur programme plutôt que d’appeler un outil de contrôle externe.

Vers une évolution structurelle pour la DSN : le transfert du calcul des cotisations

Au delà ces changements techniques, la plus grosse avancée serait de déporter le calcul des cotisations sociales de l’entreprise vers les OPS. Comme l’expliquait Renaud Vatinet dans sont article La DSN : Quand la protection sociale entre dans une nouvelle ère, les informations portées par la DSN permettraient aux organismes de recouvrement de calculer l’ensemble des cotisations dues puis de retourner ces montants à l’entreprise qui pourrait si elle le souhaite vérifier les calculs.

Le régime agricole, au travers de la déclaration trimestrielle des salaires permettait jusqu’ici le pré-calcul des cotisations et leur appel chiffré. La MSA se positionne donc d’une certaine manière en précurseur sur ce sujet. J’avoue cependant ne pas comprendre comment était assurée la cohérence entre les appels trimestriels et les cotisations apparaissant sur les fiches de paie mensuelles des salariés…

Ce calcul déporté est un enjeu majeur pour le bien de notre système social. Une étape intermédiaire est possible : la création d’un répertoire unique et exhaustif des règles de calcul des cotisations et des exonérations. Là où logiciels de paye gèrent la complexité de la paie en ventilant les salariés par profiles de paye, il serait envisageable que les OPS créent et maintiennent un profil unique et un algorithme (abstraits via des fichiers XML et XSLT ?) permettant de calculer l’ensemble des lignes du bulletin de salaire de n’importe quel salarié Français (de droit privé). Les logiciels de paie privés continueraient à effectuer de manière autonome les calculs en exécutant scrupuleusement les règles de cette base. C’est techniquement moins complexe que la répartition des calculs entre tous les OPS mais cela apporte une bonne partie de la valeur attendue et donne une visibilité concrète pour piloter les futures réformes.

Une attention particulière devrait être portée :

  • à la gestion annualisée au fil de l’eau (plus de régulation en janvier n+1) du plafond de la sécurité sociale et autres cumuls du même type le cas échéant
  • à l’enrichissement du répertoire commun des déclarants, du RIE de l’ACOSS et du RNE de la MSA avec les données portant sur les zones géographiques sujettes à exonération de cotisations
  • aux interactions entre les conventions collectives et le calcul des cotisations sociales le cas échéant
  • à la prise en compte au plus tôt de cet objectif dans le développement de Cléa, futur système de recouvrement des URSSAF replaçant le SNV2

Reste à voir s’il est plus simple pour les OPS de supporter la complexité technique de répartition des calculs (chacun dans son coin avec synchronisation en temps très contraint/temps réel) ou bien de se mettre autour d’une table pour créer cette base de règles faisant référence et opposable.

La DSN est un des outils pour construire le système de demain

La DSN peut être vue comme une couche d’abstraction à la complexité historique de notre système de protection social. Un peu comme SESAM-Vitale pour l’assurance maladie, il permet de simplifier la vie des citoyens et des entreprises, de rendre plus efficients les OPS… et de redonner des leviers de réforme aux pouvoirs publics. En normalisant les relations entre les administrations et les tiers, de potentielles fusions ou transferts de compétences sont rendues un peu plus abordables.

Parmi les réformes très politiques envisageables qui tireraient un avantage de la DSN, on peut notamment citer :

  • le recouvrement des cotisations de retraite complémentaires du régime général par l’URSSAF
  • le rapprochement (fusion ou adossement) des régimes maladie préconisé par l’IGAS ou la convergence vers un régime maladie universel
  • la question complexe du prélèvement de l’IR à la source (ce qui suppose une individualisation de l’impôt et une phase transitoire complexe) qui pourrait être traitée en parallèle d’une hypothétique fusion de l’IR et de la CSG
  • la liquidation et le versement unique des pensions de retraite vers lesquels tend la toute nouvelle Union Retraite voire le rapprochement des régimes de retraite
  • la mensualisation des droits à la retraite
  • le rapprochement entre l’ACOSS et la DGFiP qui ont des besoins fonctionnels en partie similaires bien que la séparation entre les sphères fiscale et sociale soient très ancrées dans notre culture. On voit d’ailleurs que la DSN sert déjà de véhicule technique pour des données fiscales (notamment pour l’établissement de la CVAE).
  • l’abrogation de toute spécificité légale ou règlementaire de l’Alsace-Lorraine issue du rattachement à l’Allemagne entre la guerre de 1870 et la première guerre mondiale
  • la soumission des organismes paritaires aux PLFSS
  • le recalcul mensuel des droits sociaux et notamment ceux de la branche famille (même si la non disponibilité de ces données à rythme mensuel pour les indépendants risque de créer une inégalité de traitement inconstitutionnelle)
  • la diminution du non recours avec peut-être un jour la liquidation automatique des prestations sociales et un contrôle a priori de leur bonne répartition… voire même leur entrée dans l’assiette des revenus imposables

La simplification du bulletin de paie : un cache-misère contre-productif

Si la création de la DSN est le premier pas d’une démarche salvatrice pour le symbole de notre solidarité nationale, d’autres initiatives soit disant simplificatrices me semblent particulièrement contre-productives. La plus médiatique concerne la pseudo simplification du bulletin de paye.

Le gouvernement envisage en effet de regrouper les lignes de cotisation ayant trait au même domaine de protection sociale (maladie, retraite, chômage, famille) sur les bulletins de salaire.

Regrouper ces lignes est un cache misère grossier :

  • les entreprises devront continuer à calculer le détail de ce quelles doivent au titre des différentes cotisations et aux multiples OPS mais elles devront en plus calculer l’agrégat imprimé sur la fiche de paie
  • le regroupement de ces lignes complexifie la vérification des calculs par le salarié, ce qui est sensé être le fondement du bulletin de salaire
  • le regroupement des cotisations versées à des opérateurs publics et des assureurs privés à but lucratif (part complémentaire) encourage au désengagement de l’État
  • chaque cotisation représente un devoir, pendant d’un droit social acquis au cours des cinquante dernières années.
  • pour ce qui est de l’argument écologique : mieux vaudrait laisser aux URSSAF la création d’un espace en ligne permettant l’accès gratuit aux bulletins de salaires dématérialisés plutôt que de récréer une usine à gaz imposant aux entreprises de payer un tiers de confiance.
  • faire croire aux citoyens que le système de protection sociale est lisible au lieu de le réformer en profondeur ne serait qu’une magouille politique lamentable. Autant ne rien faire.

D’autre part, ce projet remet en question l’affichage de la part patronale des cotisations sur le bulletin de salaire. En tant que salarié je trouve indispensable de savoir combien je coute à mon employeur. Plutôt que de supprimer des informations, il vaudrait même mieux à terme faire apparaitre sur ce bulletin les réductions d’impôts comme le CICE ou à minima les exonérations (explicitées en DSN) qui pèsent sur nos finances publiques mais visent à améliorer notre compétitivité.

Tout cela pousserait peut-être à rationaliser le système tout en rendant l’information plus lisible pour le salarié et les calculs plus simples pour les entreprises. Les seuls perdants : les intermédiaires faisant leur beurre de la complexité déraisonnable du système ; qui restent malheureusement indispensables aujourd’hui.

Odoo : le leader des ERP libres sur la mauvaise pente

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

ebicsPy : ma première lib publiée sur Pipy

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.

Diplômé, enfin

Bonne nouvelle du jour : je viens de recevoir une jolie attestation de diplôme de la part de l’UTC. En fait, c’était plutôt un beau cadeau d’anniversaire puisque le jury de diplôme s’était réuni le 18 mars, jour de mes vingt-quatre ans.

J’ai même pu validé le mineur de science humaine Formation Internationale aux Relations Mondialisées de l’Entreprise avec mention. Si ça en intéresse certains, la synthèse de mon parcours au sein de ce mineur est disponible. Ce document cloture un parcours d’une dizaine de travaux en rapport avec économie, la technologie et l’entreprise rédigés dans le cadre des enseignements de sciences humaines que j’ai choisis. Ce mineur reflète une bonne partie des atouts de l’UTC : ouverture à l’international, choix des enseignements totalement libre et diversité des contenus (une petite centaine d’UV en sciences humaines).

Le Graal, enfin. Ce n’était pourtant pas évident vus mes débuts mouvementés en prépa-intégrée…

Petite note sur le processus de sélection de l’UTC :

Une première partie des places disponibles en cycle préparatoire sont distribuées en juin. Une part non négligeable sont attribuées qu’après un second classement, début juillet, juste après les résultats du Bac. Je viens d’un lycée de centre ville où le niveau est bon… et où les meilleurs éléments étaient regroupés dans une même classe en terminale et où certains profs faisaient tout pour terminer le programme en mars. C’est ainsi que ma moyenne de maths a plongé en terminal sans que cela ne m’empêche d’obtenir une très bonne note au Bac.

Le système de sélection de l’UTC permet donc de retenir deux profils :
* les élèves ayant eu de très bons résultats en terminale, qu’ils aient eu une panne au bac ou pas (bien que pour sécher au bac, ils doivent être extrêmement stressés…)
* les élèves ayant eu des résultats moyens dans une classe de très bon niveau qui décrochaient de bonnes notes le jour du bac

h-12

Plus de trois mois qu’on attend la keynote de Xavier. J’espère qu’elle apportera quelque chose de nouveau et d’intéressant. En théorie et malgré ce qu’ont annoncé les médias depuis ce matin, cette keynote concernera le fixe.

Alors, qu’est-ce que Xavier va nous proposer ?

La Freebox v7 ne sera vraisemblablement pas disponible avant Noël. Annoncer les villes concernées par l’accord de mutualisation conclu avec Orange en 2011 ne justifie pas une keynote. Une Freebox « alternative » ou un accessoire du style domotique paraissent un peu léger.

Les idées de « petites » innovations insuffisantes pour faire monter Xavier sur les planches ne manquent pas. S’il s’agissait du mobile, j’aurais imaginé la désolidarisation du numéro et de la carte SIM. Si Free voulait concurrencer frontalement Google ils proposeraient de l’auto-hébergement (notamment email, fichiers…)… mais ça serait bizarre pour un FAI qui est contre le principe de neutralité du net et s’est permis de bloquer les flux d’une régie publicitaire. Free pourrait déjà proposer du reverse DNS sur de l’IPv6.

Répondre à Bouygues sur les prix du fixe n’est pas nécessaire pour Free mais pourrait être une stratégie pour affaiblir la concurrence. Mis à part intégrer l’offre AliceBox intiale et tuer définitivement la marque lowcost… je ne vois pas trop ce qui serait si révolutionnaire.

Pourvu que ça ne soit pas uniquement une « innovation » tarifaire. Je remercie Free d’avoir divisé par cinq les prix du mobile en trois ans mais la culture Free c’est également (avant tout ?) une culture de technophiles… enfin c’était. À la belle époque les pubs n’étaient pas alignées sur les spots sans saveur d’Apple. À cette époque Free ne donnait pas d’argent à un taré pour « designer » sa box (comprendre la rendre bancale et bardée de lettres idéales pour conserver la poussière et porteuses de théories scientifiques probablement non maitrisées par l’auteur). Une fois le tarif fixé à 29€99, les nouveautés proposées avaient été principalement techniques (SIP, ring back tone, Mod, Freeplayer, Multipostes…).

J’espère me tromper. J’espère que la bande de geeks répondra de nouveau présent. Le teasing est à la hauteur de mon attente : live.free.fr propose une page optimisée comme je les aime. « Surprise » en base64 dans une structure HTML sans fioriture :


  
    
  
  
    
U3VycHJpc2U=

Drame de Charlie Hebdo : la liberté est fragile

Comme beaucoup, je ne peux pas m’empêcher de faire la parallèle entre ce qui s’est passé ce matin à la rédaction de Charlie Hebdo et les attentats du 11 septembre 2001. C’est ignoble et cela constituera probablement un point de non retour.

Un autre parallèle serait l’adoption de lois d’exception qui paradoxalement limiteraient notre liberté. Avant même le drame d’aujourd’hui, certains textes allaient dans ce sens. La loi de programmation militaire fin 2013 puis la loi antiterroriste de novembre contiennent des dispositions parfois incohérentes et inefficaces qui pourraient être détournées de leur objectif initial : nous protéger. Sur le plan de l’incohérence je pense particulièrement au fait que la publication d’un même contenu peut entrainer des sanctions différentes selon le média utilisé (internet vs papier/radio/TV par exemple). Sur le plan de l’inefficacité technologique, j’aime me rappeler comment cette « grande loi anti-terroriste » devait nous protéger de l’appel au djihad en obligeant les FAI à blacklister des noms de domaines complets. C’est oublier que les terroristes qui appellent au djihad le font tout d’abord sur Twitter ou Facebook… et qu’il me parait difficile de les bloquer. Si cette disposition est appliquée il y aura donc probablement deux poids, deux mesures. D’autre part, si le blocage n’est fait qu’au niveau du déréférencement DNS (et non pas au niveau des paquets IP), changer de serveur DNS suffit à passer la « protection » !

Comme le rappelait le Ministre de l’intérieur, le seul dispositif technique efficace serait l’inspection systématique de tous les flux de manière bien plus détaillée (le DPI). Or ce genre de dispositif est pour le moment réputé… pour permettre à certains dictateurs de mieux « contrôler » leurs opposants (cf l’affaire Bull/Amesys). Il est donc, en temps normal, compliqué de faire entrer de telles technologies dans la loi française. Le souvenir des dérives des fichiers nominatifs sous l’occupation est encore présent dans les mémoires d’un certain nombre. Ma grande crainte est que le drame d’aujourd’hui permette au parlement de voter la généralisation de ce genre de technologies. Dans ces moments de grand désarroi, nous citoyens, devons encore plus veiller  à la qualité et au bien fondé des textes votés par le législateur sans jamais lui donner carte blanche.

Cette crainte « politique » est renforcée par le contexte économique. Le DPI requiert des équipements couteux. Les FAI ne sont pas prêts à se les laisser imposer sans protester, d’autant plus qu’ils n’ont toujours pas été totalement remboursés des frais engendrés par la loi HADOPI. Or il se trouve que le DPI permettrait également aux FAI de facturer très finement leurs utilisateurs en bafouant encore plus la neutralité des réseaux… mais en rapportant gros. En langage commercial policé, on appelle ça des « offres différenciées ». D’ici que l’on troque DPI pour le compte du ministère de l’intérieur contre bénédiction pour un DPI à usage commercial il n’y a qu’un pas. Un troisième type d’acteur y ferait son beurre : les équipementiers. Le SDN et le DPI sont deux caractéristiques des routeurs nouvelles générations qui justifient commercialement de hâter le renouvellement du parc.

Attention également à ne pas protéger une facette de notre liberté au détriment d’une autre. Au JT de 20h, une collègue des victimes a rappelé que l’incitation à la haine et les insultes pleuvaient sur les réseaux sociaux à l’encontre des dessinateurs du journal depuis des années. Cela me rappelle l’idée de quelques uns de  « réguler » Twitter il y a quelques mois (je ne dis pas que cette journaliste pensait à ça). C’est une pente très glissante. Le débat sur les bornes (ou l’absence de borne comme au États-Unis) de la liberté d’expression me parait très complexe. Encore plus que la dualité droit à l’oubli/droit à l’information. Tenir compte des conseils d’experts ayant une double culture technique et juridique tels que ceux de LQDN permettrait peut-être, a priori, d’éviter le pire.

Quelques lapalissades à garder en mémoire pour terminer :

  • l’indépendance de la justice passe par des juges judiciaires et non des autorités administratives
  • à propos de l’anonymat (ou à défaut le pseudonymat)  : il me parait  important de pouvoir un jour l’utiliser même s’il n’est pas souhaitable que ça advienne
  • ma liberté prend fin là où commence celle des autres

Un an après, où en est le rapport Grandguillaume ?

Le 17 décembre 2013, Laurent Grandguillaume publiait son rapport sur les entrepreneurs individuels.On y trouvait une analyse des statuts juridiques de l’entreprise individuelle, des régimes forfaitaires et réels, un comparatif des droits sociaux portés par le RSI… Dans l’ombre du projet de réforme simpliste et contreversé de Sylvia Pinel, ce jeune député de Côte d’Or avait réussi le tour de force de mettre les auto-entrepreneurs et les artisans d’accord.

Les principales recommandations d’alors étaient :

  • le maintient du principe « pas de CA, pas de cotisation sociale (ni de droits à la retraite) »
  • le maintient des seuils de sortie du statut d’auto-entrepreneur
  • le maintient de la franchise en base de TVA pour les auto-entrepreneurs
  • l’obligation pour les auto-entrepreneurs du bâtiment de s’assurer comme un artisan
  • la fusion de toutes les formes d’entreprises individuelles
  • le remplacement du prélèvement libératoire par un acompte à l’IR afin d’éviter les effets de seuil
  • la mutation de la CFE et la CFP en taxes proportionnelles au CA pour les entreprises individuelles
  • l’accompagnement progressif vers le régime réel

En 2015, les cotisations minimales pour les entrepreneurs au réel seront réduites et appelées dès l’année N+1. Les dispositions spécifiques au maintient des seuils du statut et à l’obligation d’assurance des auto-entrepreneurs ont été reprises dans la loi Pinel. On note également la fusion du micro-social et micro-fiscal en un seul régime de la micro-entreprise par décret, au plus tard le 1er janvier 2016.

Les propositions d’accompagnement vers le réel et de réforme de la CFE n’ont pas été retenues. La proposition emblématique (car non politique mais structurellement simplificatrice) de fusion des statuts juridiques de l’EI est en cours d’instance au ministère de la justice.

Le rapport de Laurent Grandguillaume aura donc permis de stabiliser et sécuriser un dispositif favorisant l’esprit d’entreprise et de tracer les grandes lignes des prochaines évolutions. Ces réformes structurelles restent à faire. Outre la fusion des statuts juridiques de l’EI et la fin du prélèvement libératoire de l’IR, on pourrait ajouter la fusion des Centres de Formalité des Entreprises dont la lecture est pour le moment complexe et peu convaincante.