PROJET AUTOBLOG


Aurélien Dumaine

Site original : Aurélien Dumaine

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

L’internalisation du calcul des cotisations sociales plus intéressante que le prélèvement à la source ?

dimanche 19 juin 2016 à 06:26

Le prélèvement à la source s’annonce comme LA réforme technocratique et politicienne du quinquennat. Est-ce réellement une priorité pour l’intérêt général ? N’y a-t-il pas des réformes de fond, plus progressives, moins coûteuses et plus simplificatrices à mettre en œuvre ? Je propose une alternative. À débattre !

Le prélèvement à la source : plan de com’ pré-électoral ?

Le prélèvement à la source de l’impôt sur le revenu sera, sauf trébuchement constitutionnel, mis en oeuvre dès janvier 2018. C’est une réforme à forte visibilité, supposée simplificatrice, à un an du renouvellement de notre monarque républicain. La chose sera suffisamment avancée pour apparaître comme acte de modernisation du pays à l’actif du bilan du sortant mais pas suffisamment pour être déjà entachée de potentiels problèmes techniques. Bien pratique donc !

À défaut de grande réforme fiscale de fond politiquement compliquée(fusion IR/CSG, renforcement de la progressivité du barème, TVA sociale, taxe écologique…), le gouvernement pourra afficher une mesurette qui pourrait malgré tout poser des problèmes opérationnels. Sans compter que l’opposition parlementaire jurera la main sur le cœur de l’abroger ; même si elle envisageait elle-même la mesure il y a peu. Elle risquerait de balayer les importants investissements techniques déjà réalisés si elle arrivait au pouvoir dans les mois suivants.

À mon sens, cette réforme apporte peu de simplification et constitue plutôt une avance de trésorerie faite par les salariés qui provisionnaient jusqu’ici eux-même leur impôt sur le revenu. Pis : le vecteur de déclaration automatisé (la DSN) n’étant pas encore adopté par de nombreuses entreprises (et même pas planifié pour le secteur public), le dispositif pourrait devenir une nouvelle charge administrative.

Ne jetons pas le bébé avec l’eau du bain : le prélèvement à la source va dans le sens de l’histoire. La France  rejoindra ainsi pas mal de nos partenaires à l’heure où l’harmonisation fiscale est perçue comme un nouvel élan pour la construction européenne. Cela suffit-il à faire du prélèvement à la source une priorité servant l’intérêt général pour autant, c’est une autre question…

L’internalisation du calcul des cotisations sociales

Comme déjà évoqué il y a un an, la Déclaration Sociale Nominative confirme son rôle de levier de simplification pour les employeurs, les organismes de protection sociale et les éditeurs. Je pense justement qu’il aurait été plus intéressant d’aller plus loin dans le développement de la DSN avant de se lancer dans le prélèvement à la source.

La philosophie générale de la DSN est de demander aux entreprises un minimum d’informations à un niveau de granularité fin et de laisser l’administration générer les agrégats dont elle a besoin. Cependant, dans le modèle actuel, les entreprises doivent continuer à calculer elles-mêmes les nombreuses cotisations dûes aux différents collecteurs de notre système de protection sociale. Dans les faits, elles font appel à un tiers-déclarant (cabinet d’expertise comptable ou organisme de gestion) ou investissent dans de coûteux logiciels de paie complexes à maintenir en cohérence avec la législation. Chaque bulletin de salaire coûte en moyenne 20€ à un employeur.

Dispenser de ces calculs de cotisations les entreprises qui le souhaitent me parait plus intéressant que le prélèvement à la source de l’IR.

Généraliser et unifier les dispositifs existants

Internaliser le calcul des cotisation sociales dans les organismes recouvreurs n’est pas une idée nouvelle. Les TPE et les particuliers employeurs disposent dores et déjà de services permettant de simplifier l’embauche la gestion du salarié. Ces services permettent :

Conscient de l’intérêt pour les entreprises, le gouvernement a élargie le dispositif aux entreprises de 20 salariés. Le dispositif reste cependant incomplet et exclut de facto de nombreuses entreprises. De plus ces dispositifs ne sont pas du tout inter-opérables avec le SI de l’entreprise.

refonte_TESE_DSN

Urbaniser le SI en cohérence avec l’État plateforme

Le SI des URSSAF, le SNV2, ne permettant pas pour le moment la gestion des cotisations à la maille individuelle. À défaut d’attendre sa refonte (programme Clé-A), il serait possible de génériser le SI du TESE et de l’urbaniser avec de le rendre modulaire et inter-opérable. Ce système de « Titre emploi Service Unifié » (TESU) pourrait être utilisé par les entreprises volontaires afin de gérer, de manière plus ou moins complète, la paye leurs salariés.

Quelques propriétés fonctionnelles :

Quelques propriétés techniques :

Quelle valeur ? Quelles limites ?

Ce projet, au premier abord technique, rebat une partie des cartes et permet :

Dans le cadre du référentiel générale des carrières unique, certains régimes ont souhaité conservé leurs modules de calculs sur leurs infrastructure. Mettre tous les régimes d’accord pour utiliser un moteur commun et mutualiser au niveau des règles semble primordial en termes de performance et d’urbanisation.

La performance globale de la plateforme pourrait poser problème : s’il on lance 16 millions de payes (soit une seule par salarié français) au même moment, l’architecture nécessaire pour tenir la charge serait potentiellement importante. Une ouverture maîtrisée et progressive du service serait donc nécessaire. Cette conception architecturale permet néanmoins une réutilisation maximale de chacun des composants, open-source, qui deviennent des biens communs. Ils peuvent être instanciés chez les déclarants, éditeurs ou tiers-déclarant, ce qui soulage d’autant l’infrastructure du service.

 

Protégé : Ouverture des SI tirée par la donnée : quelles conséquences en termes de projet ?

dimanche 12 juin 2016 à 18:46

Cet article est protégé par un mot de passe. Pour le lire, veuillez saisir votre mot de passe ci-dessous :

Let’s Encrypt : sécurité pour tous ou passoire pour tous ?

lundi 18 avril 2016 à 00:37

Let’s encrypt vient de sortir de sa version béta. Ça m’inspire une petite réflexion à deux balles du dimanche soir.

Chaîne de confiance et authentification des sites web

Les concepteurs de certains sites web choisissent parfois de chiffrer la connexion entre votre navigateur internet et le serveur sur lequel est hébergé le site web. Cela peut avoir plusieurs finalité : éviter qu’un des intermédiaires entre votre navigateur et le dit serveur n’obtiennent des informations confidentielles (mots de passe, informations de paiement) ou puissent connaitre les pages que vous avez consultées sur ce site (page wikipedia traitant de droits de l’homme dans une dictature par exemple). Pour faire simple, lorsque vous vous connectez, un échange de clés intervient afin que chacun puisse chiffrer les données envoyées. Le chiffrement de ce flux d’octets entre vos deux machines se matérialise par le fameux « cadenas » dans votre navigateur.

Au delà d’une écoute passive, les nombreux réseaux que traversent ces octets pourraient décider de se faire passer pour ledit site web. Il est donc nécessaire que le serveur répondant à la requête de l’utilisateur prouve qu’il est bien celui qu’il prétend être. Pour cela sa clé publique (ie son certificat) est signé par une autorité de confiance. Lors de la connexion de votre navigateur web, celui-ci vérifie que le certificat envoyé par le serveur correspond au domaine demandé. Il  utilise ensuite à la clé publique de l’autorité de confiance qui a signée ce certificat (ou le certificat d’autorités intermédiaires) pour vérifier l’authenticité du certificat transmis. Cette clé est stockée localement au sein du navigateur. Les navigateurs du marché sont donc distribués avec les clé publiques d’un nombre limité d’organisations reconnues pour être des tiers de confiance.

NB : L’architecture présentée ici ne fonctionnent bien évidement pas qu’avec le web mais cet exemple est particulièrement pédagogique.

Pourquoi Let’s encrypt ?

Lorsque j’ai installé dumaine.me sur un vieil ordinateur portable situé sous mon bureau, trois possibilités s’offraient à moi :

Pour des questions pratiques, j’ai choisi cette troisième option. J’ai demandé à la seule autorité de certification (reconnue sur tous les OS par les navigateurs les plus utilisés) gratuite que je connaisse de signer mon certificat : StartSSL.

Ces organisations, la plupart à but lucratif, ont pour modèle économique de garantir différents niveaux de confiance, liés à différents niveaux de vérification, d’informations circulant sur internet, et principalement des certificats évoqués ci-dessus. StartSSL propose une gamme gratuite mais comportant certaines restrictions.

De nombreuses machinent hébergent des données personnelles sans chiffrer leur échanges car leur propriétaire n’a pas les moyens techniques et financiers de les sécuriser. Let’s encrypt tend à satisfaire ce besoin : il fournit une suite logicielle facilitant la configuration des serveurs web et propose de signer gratuitement les certificats produits via une autorité de certification reconnue (celle de Cisco en l’occurrence).

Quelles limites ?

Depuis son lancement à l’automne, la part des sites chiffrant leurs communications a augmentée significativement. Certains industriels incluent aujourd’hui les certificats Let’s encrypt dans des produits grands public (NAS, Freebox, domaines OVH, Gandi etc). De nombreuses données personnelles et/ou sensibles qui circulaient en clair il y a un an sont aujourd’hui chiffrées. Une victoire de plus pour Canard ? Ce n’est pas si simple…

Cette architecture de tiers de confiance constitue, avec le DNS et la hiérarchie des opérateurs (tiers 1 / tiers 2 / tiers 3), l’une des seules choses non horizontales, non distribuées (au mieux décentralisées) de l’architecture d’internet. Le fait que de nombreux utilisateurs passent par le même acteur pour chiffrer leurs communications peut potentiellement diminuer la résilience de l’ensemble. Cette autorité de certification devient un hony pot de plus en plus appétissant, que se soit en terme d’attaques ou de pressions politiques.

Le scandale Snowden a confirmé les craintes de la communauté informatique internationale : certains gouvernements espionnent massivement leur population. Let’s encrypt pourrait potentiellement leur faciliter le travail. L’épisode Lavabit confirme les pressions exercées sur des acteurs ciblés outre atlantique.

Dans la série « C’est quoi le pire ? » : se croire en sécurité lorsque ce n’est pas réellement le cas ou savoir que l’on est pas du tout en sécurité ? À partir de quand est-on « réellement » en sécurité ? Cette notion a-t-elle un sens indépendamment du contexte ?

Néanmoins, la formalisation d’un protocole (ACME) visant à simplifier la configuration et le renouvèlement de certificats, fussent-ils ou non distribués via l’autorité de certification Cisco, est une amélioration significative et aidera à la démocratisation de l’auto-hébergement.

Au delà de l’aspect technique, Let’s encrypt a une vertu indéniable : son buzz contribue à mieux faire connaitre des points fondamentaux de la sécurité informatique. Et qui sait, cela induira peut-être l’émergence d’une alternative réellement distribuée ? Des pistes sont actuellement explorées du côté de la blockchain…

#CodeImpots : premier bug ?

vendredi 1 avril 2016 à 15:13

Mise à jour : si l’article posté était bien un poisson d’avril, le lien entre potentiels bugs et pratiques d’ouverture n’en reste pas moins intéressant.

Le code source de la calculatrice des impôts a été présenté ce matin. \o/ L’un des participants au hackathon #CodeImpots aurait découvert un bug d’arrondi qui pourrait engendrer des rappels si c’est réellement ce code qui est en production à la DGFiP.

Il va être intéressant de voir comment réagissent les autorités. Aux extrémités, je perçois deux postures :

  1.  « L’erreur est humaine, si nous avions partagé ce code plus tôt nous n’aurions peut-être pas poussé cette erreur en production. Le partage donne l’occasion à nos agents d’améliorer continuellement nos applications et nous leur en donnerons les moyens. Ce changement de culture se fera progressivement mais il faut prendre le pas tout de suite. Cette nouvelle pratique est la suite logique des démarches de mutualisation des SI. »
  2. « Ce coup de com’ était sympa mais revenons à nos pratiques ancestrales et à une opacité totale où l’on peut imaginer faire les choses parfaitement sans que ce soit vérifiable. Nous utiliserons à l’avenir l’exception de sécurité nationale de la loi pour une République Numérique pour bloquer toute nouvelle tentative d’accès par la CADA (article 1 bis du texte présenté au sénat). La volonté politique de changement n’est pas assez forte. »

Je croise les doigts pour que le premier cas l’emporte durablement !

Petite satisfaction personnelle pour terminer : la DGFiP a décidé d’utiliser Python pour développer son interpréteur. Mon langage préféré se diffuse donc au delà d’OpenFisca dans la sphère publique. 😉

WebUSB : un pas de plus vers l’omnipotence des navigateurs web

lundi 29 février 2016 à 15:17

Oracle a récemment annoncé que les Applets Java seraient dépréciés à partir de la version 9 du JDK (à paraître en 2017). Une annonce de plus vers la fin des plugins au sein des navigateurs, entamée depuis longtemps par AdobeFlash pour diverses raisons.

Si les applets seraient fonctionnellement remplaçables par JavaWebStart, cette disparition devrait plutôt se faire au profit de l’éco-système HTML5. WebGL, web-socket, web-workers, webRTC/ORTC ou le contreversé Encrypted Media Exetensions : de plus en plus de standards du W3C (voire conjoints à l’IETF) tendent à rapprocher, à tord ou à raison, nos navigateurs web de machines virtuelles complètes. Il reste cependant des choses encore hors de leur portée, notamment en termes d’accès à nos périphériques.

Depuis quelques années, le W3C forme des groupes dédiés à la construction d’API haut niveau spécifiques à chaque catégorie de périphériques standards (webcam, micro…). D’une part cette approche exclut durablement tous les périphériques exotiques. Une startup ayant développé un nouveau gadget ne pourra pas proposer à un tiers de développer une application web l’utilisant sans installer des drivers sur la machine de l’utilisateur, machine pouvant être tout aussi exotique que le gadget à piloter.

D’autre part, même les périphériques « classiques » ne sont pas encore tous supportés. Un exemple : les dispositifs de signature électroniques à carte SIM (ou smartcard), tels que ceux utilisés en France pour signer les réponses à appels d’offres publics. Ni l’API WebCrypto ni l’API Key Discovery ne permettent de se passer du middleware, alors même qu’un standard USB (le CCID) est dédié à ce type de périphérique (voir ici ou ). Ce manque été abordé lors du workshop « Authentification, hardware tokens and beyonds » en 2014 mais l’implémentation de CCID dans les navigateurs ne semble pas à l’ordre du jour.

Ces deux freins pourraient bientôt sauter : un draft W3C non officiel, mis à jour le 17 février 2016 par des employés de Google, spécifie l’accès bas niveau à l’USB depuis un navigateur web. D’après leur wiki, Firefox est également intéressée par WebUSB depuis 2011. Affaire à suivre…

À noter : le développement de l’accès bas niveau à l’USB n’est pas opposé à la création d’API haut niveau centrées sur un type de périphérique puisqu’elles permettent l’accès à tous les périphériques de ce type ; même s’ils ne sont pas connectés en USB.

Can't retrieve feed: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed