Catégorie : Non classé

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.

Quitter Google : ma grande aventure

J’ai commencé à utiliser quotidiennement les services de Google (Gmail, Reader, Calendar, Talk…) en août 2010 lorsque j’ai acheté le Samsung Galaxy Spica sous Androïd que j’utilise encore aujourd’hui. Peu de temps après, j’ai commencé à discuter de l’emprise de ces grosses entreprises sur nos données personnelles avec Simon, un ami UTCen. Plus nous en parlions, plus il devenait évident qu’il faudrait tôt ou tard trouver une solution alternative. Simon s’y est mis très rapidement. Pour ma part ça a été beaucoup plus progressif. J’ai reconverti un vieux PC en serveur à l’été 2012 pour n’acheter un nom de domaine et installer un serveur email que fin novembre 2012. J’ai encore mis un an et demie avant de basculer complètement. Depuis hier, je peux le dire : j’ai enfin quitté Gmail.

Je vais essayé de faire un panorama des questions qui se posent lorsque l’on décide de s’auto-héberger. Tout d’abord je souhaite remercier les personne qui m’ont directement ou indirectement aidé dans la démarche : Simon, Jocelyn Delalande, Benjamin Sontag, les rédacteurs de www.auto-hebergement.fr et tous ceux qui aident les petits nouveaux.

Le serveur sera-t-il chez moi ou dans la salle blanche d’un hébergeur ?
Quel fournisseur d’accès à internet dois-je choisir ?
Quel nom de domaine choisir ?
Quel OS installer sur ma machine ?
Quel certificat TSL ? Quel chiffrement sur HTTP ?
Puis-je réellement héberger mes emails en toute sécurité ?
Comment chiffrer mes emails ?
Quelle méthodologie de sauvegarde mettre en place ?
Doit-on préférer les applications web ou les applications natives ?
Quelle technique d’identification utiliser ?
Quels autres services voudrais-je installer dans les mois à venir ?
Quels sont les autres services du quotidien qui me lient toujours à Google ?

Le serveur sera-t-il chez moi ou dans la salle blanche d’un hébergeur ?

J’ai choisi d’héberger moi-même physiquement mon serveur car c’est ce qui se rapproche le plus de la philosophie d’internet : chaque ordinateur connecté reçoit et émet des données(fournit des services). De plus on parle beaucoup aujourd’hui des problèmes d’interco notamment entre Google et les opérateurs de détail européen. Le peering, l’échange de données entre deux réseaux, est historiquement gratuit et équilibré. La centralisation des lieux d’hébergement et entre autres les vidéos de Youtube (et on risque de parler rapidement de Netflix) mettent en cause cette externalité positive sur laquelle repose internet. Héberger mon serveur chez moi est donc en quelque sorte un acte « militant » prouvant que l’intelligence du réseau Internet est toujours en périphérie, même aujourd’hui.

Attention cependant, ce choix implique quelques inconvénients. La disponibilité de votre serveur est tributaire du bon fonctionnement du réseau électrique et de votre connexion internet. De plus, si vous êtes soucieux de l’écologie, il faut faire attention lors du choix de votre machine. J’ai racheté l’ordinateur portable d’un ami. Je ne sais pas exactement combien il consomme mais à l’année ça doit être relativement important. Notez que l’achat d’un portable est intéressant car avec une batterie vous avez un onduleur intégré pour éviter les arrêts brutaux en cas de coupures, plus fréquentes que l’on ne croit, du réseau électrique.

Un dernier point à vérifier est votre débit en upload. Si vous souhaitez pouvoir utiliser de manière fluide votre serveur, vous devez disposer d’un débit montant correct.

Quel fournisseur d’accès à internet dois-je choisir ?

Le choix du fournisseur d’accès internet n’est pas anodin. Globalement le débit montant dont vous disposez ne dépend plus aujourd’hui du choix votre FAI mais de la qualité de votre boucle locale (je parle du cuivre). C’est physique et vous n’y pouvez rien.  En revanche, si vous souhaitez disposer de tous les services dont votre serveur aura besoin pour fonctionner de manière optimale, le choix du FAI est capital. L’idéal serait d’adhérer à un fournisseur de la Fédération French Data Network qui sont des associations locales, à taille humaine, fournissant de l’internet neutre (désolé, c’est sur Youtube) et luttant pour qu’internet redevienne neutre.

Si vous devez choisir parmi les 5 grands FAI commerciaux Français (parce que Papa ou Maman veut la télé par ADSL par exemple) je vous conseille très vivement que choisir Free qui fournit facilement les services suivants : IPv4 fixe, d’une IPv6, d’un port 25 ouvert, d’un reverse DNS IPv4. Orange est le pire : il n’en fournit aucun. Orange est resté bloqué à la mentalité minitel et ne fournit qu’un moyen de consommer goulûment des octet sur le réseau, il ne fournit pas un accès internet.

Je vais également essayer de lister mes déceptions au cours de cet article. Première déception : Free ne fournit pas encore de reverse DNS IPv6, ce qui semble compliquer les choses : il faut forcer l’envoi SMTP en IPv4 vers les serveurs vérifiant le reverse DNS en IPv6.

Quel nom de domaine choisir ?

LA grande question ! Sachez que si dans un premier temps vous souhaitez juste « jouer » avec votre serveur, vous pouvez soit utiliser votre IP, soit un domaine gratuit du genre No-ip ou des TLD en .tk. Free vous permet également de choisir gratuitement votre nom de domaine en hd.free.fr.

Au delas de la phase de test, il vous faudra louer un nom de domaine auprès d’un registar. Je vous conseille de choisir un registar qui sera capable, si un jour vous en avez besoin (peut-être même en urgence) d’étendre les services que vous lui louez à de l’hébergement email, web ou bien à un serveur complet dans ses baies. On ne sait jamais, ça peut toujours servir. Dans cette optique, je vous conseille de choisir un registar français ou européen (ie, dans l’UE). Entre les outils légaux (Patriot Act) et illégaux (cf Snowden et NSA) de nos amis États-Uniens, je préfère rester en Europe. D’autre part, je ne suis pas sur qu’il soit possible de réserver de .fr auprès d’un registar outre-atlantique.

Choisissez bien votre nom de domaine car il vous suivra probablement pour les années ou décennies à venir. Pas trop long, facile à dicter…. Évitez aussi les noms de domaine avec des caractères spéciaux (lettres accentuées, idéogramme, cyrillique…) appelés IDN. Notez qu’il y a régulièrement des promotions chez les grands registars (OVH, Gandi…).

Si votre bureau d’enregistrement vous fait des misères, il est facile de migrer son nom de domaine vers un autre registar proposant la même extension. La procédure est normalisée, automatique et rapide.

J’ai choisi OVH. Une petite déception : ne pas pouvoir choisir un TTL inférieur à 24h pour ma zone DNS.

Quel OS installer sur ma machine ?

Bien évidement, je vous conseille très très vivement d’installer une distribution GNU/Linux. Debian me paraît stable, très bien documentée et tout à fait adaptée à cette utilisation. Tous les logiciels dont vous aurez besoin seront disponibles compilés dans les dépôts.

Cependant, si vous souhaitez limiter le temps de paramétrage de votre serveur, Yunohost (dérivée de Debian) est l’idéal. Tout y est déjà pré-configuré pour un serveur complet et sécurisé. Cela dit, configurer au moins une fois tous les composants d’un serveur juste pour bidouiller est très formateur. D’autres interface web d’administration existent telles que AlternC (initié par Valentin Lacambre puis réécrit par l’équipe de l’AutreNet), le traditionnel Webmin… Cependant ces projets semblent plus orientés hébergement massif professionnel que serveur all-in-one avec intégration pré-machée pour auto-hébergement personnel.

Valentin Lacambre

Quel certificat TSL ? Quel chiffrement sur HTTP ?

Si vous souhaitez héberger un serveur web, vous serez probablement amené un jour à vouloir chiffrer certains flux en HTTPS. Par exemple, il est inconcevable d’utiliser un webmail en HTTP. Personnellement j’ai choisis de tout chiffrer par défaut. Certains crieront au gaspillage de ressources. Je suis persuadé qu’il est bien plus simple et bien plus sûr de tout chiffrer plutôt que de m’apercevoir un jour que des mots de passe ont fuité car j’ai oublié de chiffrer l’espace d’administration de mon blog ou autre.

Pour chiffrer vos flux HTTPS, il va vous falloir un certificat TLS. Vous avez plusieurs possibilités :

  • auto-signer votre propre certificat
  • le faire signer par CAcert
  • le faire signer par StartSSL
  • le faire signer par tout autre autorité de certification reconnue (cher !)

Toujours dans une démarche d’indépendance, je suis longtemps resté avec un certificat auto-signé. Cela impliquait de créer une exception de sécurité sur le navigateur de mon PC et de valider l’avertissement de sécurité lorsque j’accédais à mon serveur web depuis un autre PC. La chose s’est compliquée lorsque j’ai décidé de chiffrer tout mon blog. Il était peu envisageable de demander à mes visiteurs de valider une exception de sécurité avant d’accéder à mes saints écrits. Je devais donc faire signer mon certificat par une autorité de certification. CA-cert a l’avantage d’être communautaire mais le certificat racine de cette autorité n’est pas installé  par défaut dans tous les navigateurs web fonctionnant sous M$ Windows. J’ai donc choisi l’offre commerciale de StartSSL : certification gratuite pour un seul sous-domaine.

Ne disposant que d’un sous-domaine, j’ai configuré Apache pour réécrire automatiquement les URL de la forme xxx.dumaine.me en www.dumaine.me/xxx/

Puis-je réellement héberger mes emails en toute sécurité ?

Il est encore un peu tôt pour répondre à cette question en me fondant sur mon expérience personnelle. J’ai un serveur email sur ma machine depuis plus d’un an mais je m’en suis peu servi pour le moment. L’excellente conférence de Benjamin Sontag sur l’email (cycle de confs de l’IEUFI) montre qu’héberger son serveur email est tout à fait faisable si on prend un minimum de temps pour s’intéresser à la config pour faire les choses correctement. À défaut, vous devrez utiliser  des outils pré-configurés comme Yunohost et mettre à jour proprement votre zone DNS.

En cas de panne d’un serveur SMTP, l’émetteur répète l’envoi durant 4 au moins quatre jours (en général, c’est une convention). Afin de ne louper aucun email si je suis en vacances durant plus de quatre jours, j’ai créé un compte sur le serveur email OVH (avec les alias qui vont bien) et je l’ai mis en serveur MX secondaire. Ainsi en cas de panne de ma machine, je réceptionne les emails sans bouncer mes correspondants. D’autre part, j’utilise un client SMTP local sur mon ordinateur personnel : j’ai donc accès à mes anciens emails quand mon serveur est hors-ligne.

Le seul risque actuellement serait que mon serveur crash (panne de disque) entre la réception d’un email et la synchro IMAP sur mon PC, la nuit par exemple. Le seul moyen que je vois pour contrer la chose serait d’exécuter automatiquement un script (via un wrapper) qui duplique l’email sur un autre serveur de confiance ou un NAS dès sa réception par mon serveur SMTP. Ça me paraît un peu lourd donc pour le moment je me débrouille sans.

Comment chiffrer mes emails ?

L’extension Enigmail de Thunderbird me parait très bien fichue. Je n’ai pas encore d’extension Roundcube pour le chiffrement. Cependant, l’extension pour navigateurs web www.mailvelope.com doit permettre de chiffrer le texte de m’importe quel champ texte. Je ne l’ai pas encore testée. Cependant, l’utilité d’un webmail est de pouvoir accéder à sa messagerie en déplacement donc lors que l’on a ni le temps ni la possibilité d’installer des extensions dans son navigateur.

Un truc pratique serait de pouvoir stocker la version déchiffrée des messages sur le serveur IMAP une fois reçus. En cas de perte de certificat dans vous pourrez toujours consulter vos anciens emails.

Quelle méthodologie de sauvegarde mettre en place ?

Le plus simple est d’utiliser cron pour sauvegarder automatiquement vos fichiers et notamment les sauvegardes de vos bases de données (fichiers .sql) chaque nuit. Vous pouvez les sauvegarder sur un disque USB ou bien chiffrer les données et les envoyer dans le cloud (dropbox, gdrive, oneDrive…). Il existe également des outils pour faire des sauvegardes différentielles (on ne copie que ce qui a changé depuis la dernière sauvegarde complète)  ou incrémentales (on ne copié que ce qui a changé depuis la dernière sauvegarde incrémentale). Rsync, lui, synchronise des répertoires distants en ne transférant que ce qui a changé. Il est assez réputé.

Doit-on préférer les applications web ou les applications natives ?

Les applications web sont pratiques car elles fonctionnent partout de la même manière, indépendamment du PC. Les applications natives nécessitent de la configuration mais sont plus économe en ressource réseau (pas besoin de tout recharger à chaque fois), gardent une copie locale des données (pratique en cas de pépin sur le serveur) et donc permettent une consultation hors-ligne.

Bonne nouvelle : il n’y a pas à choisir. Le plus important ce sont les protocoles ! La plupart des applications internet sont basées sur des protocoles ouverts et standards (codifiés dans des RFC) permettant d’utiliser un même service avec plusieurs technologies. L’IMAP vous permettra de consulter vos emails chez vous, de les classer dans votre clients lourd et de les retrouver tels quel dans votre webmail quand vous serez au boulot ou bien sur votre client mobile le weekend chez belle-maman. Le webdav permet une synchro de fichiers, le carddav des contacts et le caldav des calendriers.

Une déception : il n’est visiblement pas possible de synchroniser les groupes d’appartenance des contacts avec un serveur carddav sous Owncloud et un client Thunderbird. Je ne sais pas si c’est la faute du protocole ou bien si les implémentations sont incomplètes. De plus Owncloud agrège les différents contacts des carnets d’adresse sans pouvoir retrouver quel contact appartient à quel carnet d’adresse a postériori.

 

 

 

Application Serveur Client console Client graphique natif Client web Client Androïd natif
Envoi d’email SMTP Postfix, Sendmail Mutt, SMTPS Thunderbird, Évolution Roundcube, Horde client intégré
Réception d’email IMAP Dovecot Mutt, MS IMAP Thunderbird, Évolution Roundcube, Horde client intégré
Synchro de contacts CardDav Baikal, Owncloud  pyCardDAV Thunderbird(extension SOGO connector), Évolution Roundcube, Horde, Owncloud CardDavSync, ContactSync
Synchro agenda CalDav Baikal, Owncloud  Khal Thunderbird(extention Lightning), Évolution Roundcube, Horde, Agendav, CalDavZAP, Owncloud CalendarSync, CalDAVSync
Synchro de fichiers WebDav mod_webdav d’Apache, Owncloud Cadaver Nautilus, Konqueror WebDAV File Manager
Messagerie instantanée XMPP ejabberd Poezio, FreeTalk Thunderbird, Pidgin Jappix, Owncloud Xabber (multi-proto)
Streaming de musique Ampache mod_ d’Apache, Owncloud Amarok Amdroid,

Easy Music Transfer
Visionneur de flux RSS Pas de proto de synchro newsbeuter, raggle Thunderbird, Firefox… Leed, TinyRSS, Owncloud  Feedly, FeedR

 

Nota : Owncloud n’est pas vraiment un client CardDav/CalDav à proprement parler. Il dispose d’une interface web permettant de modifier  les calendriers et contacts qu’il contient.

Owncloud permet aussi d’héberger un serveur pour Firefox Sync. Il est là aussi dommage que ce protocole ne soit pas standard et implémenté dans d’autres navigateurs de manière inter-opérable. J’utilise actuellement la version 29 en nighlty de Firefox : je ne sais pas comment utiliser la version 1 de FirefoxSync. Seule la nouvelle version Firefox Account m’est proposée et m’oblige à utiliser les serveurs de la fondation. Ce que je refuse de faire.

Owncloud ne permet pas de gérer de reminder, et encore moins d’envoyer des email ou autres messages instantanés. C’est un gros manque.

Certaines applications sont (malheureusement) indépendantes de toute normalisation ouverte et donc non interopérables. Pour d’autres une normalisation n’aurait pas beaucoup d’intérêt car elle ne sont pas destinées à échanger avec d’autres environnements. Les applications suivantes sont également installées sur mon serveur :

  • Plateforme de blog : WordPress (un peu usine à gaz mais fonctionnel)
  • un proxy HTTP anonymisant et transparent via le module apache (pour une utilisation ponctuelle mieux vaut établir un tunnel via SSH)
  • Publication de texte anonyme (Pastebin like) : Zerobin (merci SebSauvage)
  • Partage de liens : Shaarli (merci SebSauvage)
  • Réplication automatique de blog pour industrialiser l’effet Streisand : Autoblog (merci SebSauvage et pas merci à la fois : je peux plus dire de conneries et les corriger a posteriori XD)

Je trouve dommage qu’il n’y ait pas moyen de synchroniser la liste des flux RSS ni l’état (lu ou non-lu) de chaque item de ces flux. Je trouve assez décevante l’offre d’agrégateurs RSS natifs. Je n’en ai trouvé aucun pour le moment qui permette d’afficher une liste conséquente de flux sans trop scroller, de lire directement la liste des flux en scrollant, de marquer comme lu les flux qui on été srcollés et de ne pas afficher le titre des flux qui n’ont aucun item non-lu. Du coté des applications web il m’a fallu faire une petite modif du code PHP dans Leed et une petite modif de CSS dans Owncloud (pour afficher les titres des flux en plus petit).

Thunderbird ne peut pas synchroniser un carnet d’adresse par CardDav sans extension ! À l’heure de FirefoxOS c’est un sacré problème ! De plus, lorsque j’essaye d’importer mes carnets d’adresses vCard exportés avec Gmail, Thunderbird ne récupère pas les numéros de téléphone alors que cela fonctionne très bien dans Owncloud. D’autre part, la structure du carnet d’adresse est ultra figée. Je dispose d’une cinquantaine de champs qui me sont inutiles mais je ne peux apparemment pas associer plus de deux adresses email à un contact dans Thunderbird.

J’essaye de limiter le nombre de technologies tournant en permanence pour limiter le gaspillage de ressources. Ainsi j’évite tout ce qui utilise Java ainsi que node.js(Latex Sharing,  EtherpadLite, Laverna). J’essaye ainsi de me limiter à PHP et Python.

Quelle technique d’identification utiliser ?

L’authentification entre applications (le Single-Sign-On) permet de s’authentifier une fois pour toute auprès d’un service qui sera contacté par les autres applications pour propager l’identification et les paramètres (email typiquement) d’un utilisateur. Cela permet de ne gérer qu’un seul mot de passe et donc de pouvoir le changer plus souvent et plus rapidement. Certaines solutions propose une déconnexion centralisée.

Il existe de nombreux protocole de SSO sur le web. Cependant je n’ai pas trouvé de solution réellement satisfaisante :

  • OpenID est léger mais oblige à resaisir son URL à chaque connexion dans chaque appli
  • LemonLDAP est mutli-protocoles mais lourd
  • Authentic2, de entreouvert.org est en python et multi-protocoles mais me parait complexe à mettre en oeuvre

D’autre part, assez peu d’applications libres ont mis en place ces protocoles d’authentification unique. Dans l’état actuel des choses, je reste donc avec un couple login/password par application et utilise leurs cookies pour garder ma session ouverte… sur mon PC.

Quels autres services voudrais-je installer dans les mois à venir ?

C’est pas tout ça mais y’a encore du boulot !

  • passer mes boîtes emails du format mailbox au format maildir
  • réparer le plugin depublication du taux d’accès IPv6
  • réparer les QRcode shaarli
  • installer Seive
  • supprimer l’adresse IP du client envoyant l’email des headers SMTP
  • réinstaller un serveur OpenID
  • installer Spamassassin, Amavis, ClamAV
  • importer mes notes depuis ZohoNotebook dans Onwcloud : avec une archi trois niveau et un éditeur HTML ça serait mieux
  • gestionnaire de sondages (Doodle-like) : Framadate
  • gestionnaire de sondage (Google sondage like) : Limesurvey
  • creuser du coté du projet Unhosted
  • VPN : OpenVPN
  • un portail de mashup ? Posh ?
  • un moteur de recherche décentralisé : Seek
  • TOR
  • un truc léger voir intégré dans le module de document partagé de Owncloud pour faire du Latex collaboratif en ligne
  • la mm chose pour éditer de manière collaborative des feuilles de caclus/graphique et des présentations
  • un serveur SIP : Asterisk
  • solution de confs WebRTC : pour éviter au destinataire ponctuel d’installer un soft
  • héberger mon propre serveur DNS avec Bind : juste pour jouer (pas en prod) car iveau résilience c’est moyen et ça apporte peu.
  • utiliser (voire héberger ?) un DNS alternatif
  • un gestionnaire de projet (genre un redmind léger) qui permette de ticketer et parcourir les dépots Hg
  • un back up ditant, chiffré et distribué : Thaoe FS
  • un réseau social/micro blogging : (Identi.ca, Diaspora, Movim…)
  • FTPS ? utile avec SSH et WebDav ?

Faudrait aussi que je me mette à développer des plugins pour essayer d’apporter ma pierre à l’édifice et combler certains de manques que j’ai relevés. C’est ça aussi l’esprit du libre.

Quels sont les autres services du quotidien qui me lient toujours à Google ?

Pour le moment j’utilise encore quasi exclusivement le moteur de recherche Google. Je vais essayer de me mettre progressivement à DuckDuckGo et d’installer un node Seek sur mon serveur… mais Rome ne s’est pas faite en un jour. Avec DoNotTrack activé et mon compte utilisateur déconnecté, le risque pour ma vie privé est déjà assez réduit.

J’utilise encore aussi beaucoup Google Maps. OpenStreetMap est performant mais je crois qu’on va pouvoir attendre longtemps avant de y pouvoir consulter des photos prises par satellite…

Youtube… car l’effet de réseau induit par le contenu ou la masse d’utilisateurs (comme les réseaux sociaux fermés) est bien difficile à combattre… pour le moment.

Sans compter que je suis encore présent sur Facebook et assez actif sur Twitter.

Entreprises et dématérialisation

Faisons un petit point sur les possibilités de dématérialisation des entreprises françaises.

Domaine bancaire

  • ISO20022 : norme des fichiers XML permettant les virements (SDD) et prélèvements(SCT) bancaires. Obligatoire pour les paiement libellés en euros au sein de la zone SEPA depuis le 1er février 2014(tolérance des formats nationaux jusqu’en août 2014). http://www.iso20022.org/
  • EBICS : protocole de transport des fichiers ISO20022. Utilise une PKI sur du HTTPS. http://www.ebics.org/
  • Les fichiers de restitution des opérations bancaires (relevés de comptes…) ne sont pas concernés par la deadline du 1er février 2014. Leur format est défini contractuellement avec la banque.

Domaine social

Gestion des salariés « classique »

  • DSN (Déclaration Sociale Nominative) utilisant la norme NEODES (norme d’échange optimisée des déclarations sociales) : remplacera la DADS-U pour la plupart des entreprises mi-2015 et pour les autres en 2016. Cette déclaration mensuelle sera intégrée au processus de paie. http://www.dsn-info.fr/
  • DPAE (Déclaration Préalable À l’Embauche) ancienne DUE : EFI ou EDI sur le site http://www.net-entreprise.fr/. Depuis le 1er janvier 2013, les entreprises, qui ont adressé plus de 500 déclarations d’embauche en 2012, ont l’obligation de dématérialiser leur DPAE. Cahier des charge des fichiers non publié. La DPAE sera probablement remplacé d’ici quelques années par un message « Intention d’embauche » au sein de la DSN.
  • La DOETH : EFI et EDI sur le site TéléDOETH du Ministère du Travail. La DOETH sera probablement remplacée par la DSN d’ici quelques années.
  • DAT (Déclaration des Accidents du Travail) : soit en EFI soit en EDI sur http://www.net-entreprise.fr/. Le CDC EDI est disponible sur la page suivante : http://www.ameli.fr/l-assurance-maladie/documentation-technique/declaration-d-accident-du-travail-en-mode-edi.php

Gestion simplifiée des salariés

Déclaration du dirigeant en nom propre

  • Déclaration des Revenus Professionnels de la MSA pour les non-salariés agricoles (ie les exploitants) : message EFI ou EDI.
  • Déclaration Sociale des Indépendants (ex DCR) pour les non-salariés non agricoles : disponible en EFI sur le site du RSI et NetEntreprise et éalement en EDI (format EDIFICAS).
  • Déclaration de chiffre d’affaire de l’auto-entrepreneur permettant le calcul des cotisations aux régimes micro-social simplifié, micro-entreprise (fiscalité entreprise) et l’option de prélèvement libératoire de l’IR. Disponible en EFI sur le site dédié au statut.

Domaine fiscal

Domaine de la commande publique

Il existe six possibilités pour dématérialiser les factures payables par un service de l’État :

  • saisie directement sur le portail chorus-factures.budget.gouv.fr
  • dépôt de factures au format PDF sans signature
  • dépôt de factures au format PDF avec signature
  • dépôt de factures au format XML (UBL Invoice ou UN/CEFACT
  • échange EDI via un opérateur de dématérialisation fiscale
  • échange EDI direct entre le fournisseur et l’Etat

Notez que la commission européenne souhaite harmoniser les formats de fichiers permettant la dématérialisation des factures issues des commandes publiques : http://ec.europa.eu/internal_market/publicprocurement/e-procurement/e-invoicing/index_fr.htm

La dématérialisation des factures va vraisemblablement se généraliser progressivement au cours de la prochaine décennie, tant dans la commande publique que dans les échanges entre acteurs privés. Le cabinet EY vient de publier un livre blanc sur le sujet : http://www.ey.com/FR/fr/Services/Advisory/livre-blanc-EY-dematerialisation-des-factures-fournisseurs

Domaine des douanes

À ces domaines transversaux s’ajoutent des protocoles spécifiques aux domaines métiers de chaque entreprise par exemple :

  • médecins et pharmaciens : flux SESAM-VITALE
  • buraliste/maisons de la presse : protocoles de Presstalis et  Logista France
  • grande distribution : normes du GS1
  • automobile : ODETTE
  • …

Oui à la dématérialisation, non à l’impôt logiciel !

Je suis un grand fan de la dématérialisation. J’ai commencé à faire de la vieille technologique depuis mes 15 ans sur le sujet. Je suis persuadé que c’est un élément indispensable pour la modernisation et l’efficacité des fonctions publiques… quand elle est menée correctement.

Le constat

Depuis plusieurs années, les entreprises françaises passant un certain seuil de CA ou d’imposition doivent déclarer et/ou payer tout ou partie de leurs impôts et autres charges sociales de manière dématérialisée. Ce seuil est abaissé chaque année afin de faire entrer progressivement les entreprises plus modestes dans le dispositif. Toutes les entreprises devront déclarer et payer tous leurs impots de manière dématérialisée à partir d’avril 2015. C’est selon moi une très bonne initiative. Là où le bas blesse c’est que ce passage du papier à l’immatériel a un coût qui me parait en partie injustifié.

Globalement trois solutions s’offrent à une entreprise:

  • passer par un tiers déclarant, typiquement un expert comptable
  • utiliser un logiciel générant un fichier homologué par l’association EDIFICAS puis choisir une entreprise homologuée par la DGFIP (un tiers de télétransmission ou partenaire EDI) pour transmettre le fichier à la DGFIP
  • utiliser directement la plateforme web d’un partenaire EDI qui s’occupera alors à lui seul de générer et transmettre le fichier

Si elle souhaite gérer elle-même ses déclarations d’impôts, une entreprise doit débourser beaucoup d’argent. Après avoir étudié quelques exemples, cela coûte entre entre 110 € et 900€ selon le chiffre d’affaire de la société et la solution choisie. Cela ne comprend que la création et la transmission de la liasse fiscale, ce à quoi il faut ajouter la CVAE, la TVA, EDI-REQUETE et les télépaiements.

Afin de ne pas alourdir le corps de l’article, je repousse le détail de ces exemples en fin d’article.

Les problèmes

Un impôt logiciel

Le premier problème est donc l’impôt logiciel générer par l’obligation de la télédéclaration. Si cela peut paraître dérisoire pour un groupe du CAC-40 c’est moins anecdotique pour une petite structure. Celles-ci ont souvent recourt à un expert-comptable (tiers déclarant) certes, mais ça ne justifie pas cet impôt supplémentaire… surtout quand l’administration met en avant la simplification et les gains pécuniers engendrés par la dématérialisation pour les entreprises.

Des partenaires EDI à l’utilité limitée

À quoi servent les partenaires EDI ? Pas grand chose…

Leur rôle à l’origine était de router les flux vers leurs destinataires (DGFIP, Banque de France, OGA) et de vérifier les messages avant qu’ils ne soient transmis à la DGFIP « afin d’éviter d’allonger inutilement les délais de traitement des dépôts selon la procédure EDI-TDFC » (page 196 du volume IV de la norme TDFC 2012).

Je pense qu’en 2013, la DGFIP pourrait aisément assurer ces deux rôles en permettant aux entreprises de déposer leurs déclarations sur leur compte DGFIP, exactement comme elles (ou leurs tiers déclarants) le font déjà pour leurs déclarations sociales sur le portail public et gratuit NetEntreprise. La toute nouvelle déclaration sociale nominative qui sera obligatoire en 2016 reprend exactement ce fonctionnement. Les logiciels tiers pourront même y déposer les fichiers via un process M2M utilisant des protocoles standards et ouverts.

Cette fragmentation des partenaires EDI engendre des difficultés pour les cabinets d’expertise comptable ou les OGA : si l’on veut transmettre sa liasse à un autre partenaire, il semblerait que celui-ci doit adhérer au même portail(au même partenaire EDI).

Une démarche d’homologation lourde

Actuellement étudiant en école d’ingénieur, je suis passionné par le logiciel libre depuis bien longtemps. Je suis également attiré par la gestion d’entreprise et leurs systèmes d’information. J’envisage de travailler pour une société de services en logiciels libres proposant des services autours d’Odoo (anciennement OpenERP) ; un logiciel de gestion libre.

J’ai donc commencé à développer(bidouiller serait plus juste) un outil permettant aux petites entreprises de générer leur liasse fiscale (TDFC) au format EDIFICAS qui serait facilement intégrable dans d’autres logiciels libres de gestion.

Quelle fut ma surprise à la lecture des documents de l’EDIFICAS :

  • il n’y a pas moins de 7 normes EDIFICAS, 12 scénarios d’homologation rien que pour la norme TDFC et de nombreuses sous catégories qui en font une norme illisible
  • pour faire homologuer un logiciel permettant de générer un fichier vers le portail d’un partenaire EDI cela coûte au moins entre 500 et 1000 euros (plus si l’on demande un agrément pour plusieurs scénarios) plus des frais annuels supplémentaires.

Cette procédure est donc un frein à l’entrée de nouveaux acteurs et une source de technocratie inutile.

Une norme d’un autre âge

La norme attendue par la DGFIP est fondé sur le standard international UN/CEFACT EDIFACT. C’est un format de fichiers plat complexe à manipuler datant des années 1980. La plupart des champs sont fixés par défaut ou inutilisés et les types de données sont inadaptés.

La sécurisation utilise un système de signature électronique qui oblige toute entreprise voulant elle même transférer ses liasses (et donc elle-même devenir partenaire EDI) à se rendre physiquement auprès de la DGFIP et de suivre une seconde procédure d’homologation auprès de la DGFIP.

Le dictionnaire des « champs » de la DGFIP (ne contenant pas ceux des OGA) est un classeur Excel. Il comporte même des code non-homogènes avec de ceux de l’outil de test ! Il n’y a pas de description des formulaires autre d’un fichier PDF.

La transmission des fichiers se fait via des réseaux privés coûteux et peu courants CFTAxway ou ALTLAS400-TEDECO (norme X400)

Qu’il soit obligé de transmettre de manière dématérialisée ou non, le contribuable doit encore transmettre un formulaire papier à l’administration pour s’inscrire à la dites télé-procédure.

C’est donc une norme lourde à manipuler et à mettre à jour.

Les pistes de solutions proposées

Attention à ne pas jeter le bébé avec l’eau du bain ! Toute cette infrastructure était probablement adaptée aux début de la création de la procédure TDFC ; à l’époque où les entreprises communiquaient leurs données par bande magnétique ou des réseaux « télématiques » tels que les lignes X25 et Numeris (encore mentionnés dans la norme). À l’heure où l’administration fiscale impose à ses contribuables de se moderniser ; il est urgent qu’elle donne l’exemple et se modernise elle-même avant tout. Dix ans après le début du programme Copernic, il ne faudrait pas baisser le rythme. Quelques propositions :

  • supprimer le formulaire d’adhésion à la télédéclaration
  • permettre aux entreprises de transférer leur fichier TDFC directement depuis leur compte fiscal sur le portail de la DGFIP
    • le mot de passe est sensé assurer l’authentification et la non répudiation
    • le protocole HTTPS standard assure la confidentialité de bout en bout
    • les entreprises économisent le coût du partenaire EDI
    • les tiers déclarants (cabinets d’expertise comptable par exemple) peuvent déclarer pour le compte de leurs client
    • l’administration fiscale effectue tous les contrôles et affiche les compte-rendus en HTML sur le portail (voire aussi par mail en cas de contrôles asynchrones)
    • => exactement comme le fait NetEntreprise depuis plusieurs années
  • supprimer la procédure d’homologation
    • l’administration fiscale fournit un outil de pré-validation aux éditeurs de logiciels
    • la DGFIP s’assure au fil de l’eau que les fichiers importés sont conformes
    • => de la même manière à la DADS-U(norme N4DS) et la future DSN(norme NEODeS)
  • refondre toutes les normes de déclarations fiscales
    • avoir une seule norme et un seul scénario
    • utiliser un environnement XML : un schema XML clair est bien plus pratique(tant pour l’administration que pour les éditeurs et les entreprises) qu’une norme en 8 volumes de 200 pages chacun : cela facilite la création de l’outil de pré-contrôle et la mise à jour de la norme et des logiciels
    • fournir le schema xsd permettant de vérifier automatiquement la structure du fichier XML et un fichier de transformations XSLT permettant ensuite d’effectuer des contrôles métiers (ex : contrôle de la clé d’un SIRET) et de générer un rapport XML listant les erreurs
    • fournir les templates propres des formulaires DGFIP en HTML avec une balise permettant de repérer les groupes de données répétables (au niveau des tableaux notamment)
    • s’appuyer sur le model de la norme NEODeS (norme de la DSN) pour la structuration des niveaux de contrôle et des blocs d’en-être/en-queue
  • permettre le dépôt de fichiers directement directement depuis les logiciels métiers
    • utiliser un protocole standard, sécurisé et largement utilisé sur internet pour le transport des fichiers
    • transmission en HTTPS(WebService REST bien adapté à la nouvelle norme de la DGFIP EDI-Requete) ou au pire en FTPS
    • sécurisation en réutilisant le couple login/mot de passe ou au mieux en demandant à l’entreprise d’importer une paire de clé RSA (certificat autosigné) depuis son compte fiscal vers le logiciel tiers ou inversement
  • proposer aux entreprises un mode EFI pour toutes leurs procédures fiscales
    • il est anormal que le passage du papier au numérique induise de la complexité et un coût supplémentaire (installation d’un logiciel)
    • générer une interface HTML permettant aux contribuables de remplir les formulaires dont ils ont besoin. Générer ensuite le XML qui sera transmis au back-end (de manière transparente pour le contribuable) comme n’importe quel fichier issu d’un logiciel tiers de fiscalité
    • cette interface HTML propose deux modes : un mode liste où l’on liste paires (libellés des champs, valeurs) et un mode formulaire où l’on utilise les templates des formulaires (comme si le contribuable remplissait un formulaire papier actuel)
    • bien évidement, cette interface ne proposerait aucune fonction de pré-calcul comptable. Ce type de fonctions reste la prérogative des logiciels tiers

 

 

 

Continuer la lecture de « Oui à la dématérialisation, non à l’impôt logiciel ! »

Quels mobiles subventionnés pour FreeMobile ?

Dans la série « qu’est-ce que pourrait bien nous réserver Free ? » .

Les dirigeants de Free ont récemment annoncé que Free allait rentrer sur le marché des mobiles subventionnés. En effet, le modèle du crédit à la consommation ne fonctionne pas et l’opérateur n’a pas réussi à faire condamner ses concurrent pour « crédit à la consommation déguisé ». Iliad aurait donc décidé d’investir le marché des mobiles subventionnés qui occupe encore aujourd’hui une part de marché très importante.

Xavier Niel a toujours martelé que les modèles existants prenaient en otage le consommateur et lui faisait au final payé son téléphone au prix fort. Comment pourrait-il faire ?

Il dissociera probablement la ligne de paiement du mobile de celle de l’abonnement sur la facture. Les forfaits restant sans engagement, l’utilisateur pourrait changer d’opérateur quand il le veut (sans aucun simlockage) pourvu qu’il paie à Free la part restante dûe du téléphone.

Xavier Niel permettrait ainsi à ses client de profiter des achats groupés d’un opérateur (les constructeurs vendent moins cher pour de grosses commandes) en lui laissant toute liberté de mouvement. À l’inverse, cela ne coûterait pas grand chose à Free qui respecterait son modèle sans engagement.

En somme cela reviendrait à étendre le « paiement en 4 fois sans frais » déjà pratiqué chez Free par un paiement en 24 fois sans frais avec un remboursement anticipé possible(et gratuit). Problèmes : cela est-il juridiquement possible ou se substitue-t-on alors à un organisme de crédit ? Où est la récompense de la fidélité ?

Si un abonné accepte de s’engager chez un autre opérateur, celui-ci peut lui vendre le mobile « à perte » (vendre le mobile moins cher que ce qu’il l’a acheté même avec le prix de gros du constructeur) puisque cette perte sera largement égalée par les factures suivantes. Dans le potentiel modèle décrit ci-dessus, Free ne pourrait faire bénéficier que de la réduction de gros du constructeur. Un client fidèle ne serait donc pas récompensé. Il faudrait donc y ajouter un abattement de x% du prix du téléphone à chaque mois de fidélité. Cette réduction (basée sur le prix de départ du téléphone) serait soustraite chaque mois du prix restant dû du téléphone… sans contraindre à aucun engagement.

Vu d’ici, ça paraît assez cohérent.