Catégorie : Non classé

Le G.Fast normalisé, problèmes de concurrence en perspective ?

Aujourd’hui Silicon.fr m’apprend que le G.Fast vient d’être normalisé par l’ITU. Pour rappel cette norme permet d’apporter un débit descendant d’environ un gigabit par seconde en utilisant une paire de cuivre sur les derniers mètres. Le réseau de distribution d’Orange étant de bonne qualité sur notre territoire, cela pourrait permettre aux opérateurs de proposer du très haut débit (débit descendant >= 30Mbps) en déployant de la fibre optique sur la partie amont du réseau sans avoir à rentrer dans les logements. Or c’est bien cette dernière étape qui est la plus longue et la plus coûteuse.

Quel sera l’impact réel de cette normalisation. En France, les opérateurs ne peuvent utiliser des technologies sur la boucle locale d’Orange qu’après autorisation du comité d’experts cuivre de l’ARCEP. Cette étude vise notamment à s’assurer que les signaux générés par les nouvelles technologies n’ont pas d’impacts négatif sur les lignes voisines. Dans le cas de VDSL2, il a fallu presque dix ans entre sa normalisation et l’autorisation d’exploitation par les FAI français. Pourquoi ? Je ne sais pas. La concurrence avec les réseaux fibrés pose peut-être des questions plus politiques.

Imaginons que l’ARCEP donne son accord et que des FAI soient intéressés. Ceux-ci doivent donc déployer de la fibre au plus près des logements pour ensuite installer un convertisseur opto-électrique à moins de 250 mètres (où le débit descendant chute à 150 Mbps) de la prise téléphonique des futurs abonnés. En admettant que ces convertisseurs soient fiables, durables et alimentés électriquement par le modem de l’abonné, la robustesse du réseau ne devrait pas trop en souffrir. Ma grosse interrogation concerne la concurrence entre opérateurs.

Si pour un même logement, tous les opérateurs ne disposent pas de fibres optiques dans le quartier, seulement certains pourront proposer du G.Fast. Lors d’un changement d’opérateur il faudra donc potentiellement déplacer un technicien pour rebrasser la ligne cuivre sur la collecte cuivre au point de distribution, ce qui semble très couteux. Pour éviter ce problème, on pourrait demander à Orange de mettre à disposition son réseau fibre pour le G.Fast. Se posent alors deux autres problèmes :

  • par soucis de place dans ses fourreaux et dans les NRO mais aussi par économie d’électricité(puissance des lasers) et de fibre, Orange a décidé de déployer du GPON. Chaque fibre est donc mutualisée (pour au plus 64 abonnés) en amont du point de mutualisation. Si le GFast utilise son réseau fibre, il ne sera plus possible pour les autres opérateurs de dégrouper physiquement les lignes, sauf à déployer leur réseau jusqu’au PM. Or on l’a bien vu lors de la règlementation du FTTH, l’accès à un support physique non mutualisé est une condition nécessaire à la concurrence saine entre opérateurs.
  • pour imposer aux opérateurs tiers d’utiliser la fibre Orange en amont du point de distribution, l’accès à l’ensemble de cette boucle local ne doit pas leur coûter plus cher qu’actuellement. Cela revient donc à imposer qu’Orange finance la fibre au prix de la maintenance de la boucle cuivre… alors que dans le modèle actuel Orange peut potentiellement facturer l’accès à sa boucle locale fibre bien plus cher.

Ce problème de concurrence risque d’apparaitre même sans le G.Fast : Orange a indiqué ne plus installer de ligne de cuivre dans les immeubles neufs désservis par son réseau fibre… même si ses concurrents n’en ont pas. Ce n’est que le début de la très lente extinction cuivre qui sera impactée par les recommandations de la mission Champsaur.

Je en sais pas exactement comment ni quand sera réellement utilisé le GFast sur nos lignes. Pour le moment le marché doit composer avec la fusion Numéricable/SFR/VirginMobile, un possible dégroupage du réseau FTTLA (fibre/coaxial sur un arbre DOCSIS 3.0) de Numéricable et un redécoupage des cartes de déploiement fibre entre Orange et NC-SFR.

Louvois : suite de la success story

Pour rappel, Louvois est le calculateur inter-armées initié dans le cadre du programme SOURCE qui visait à centraliser le calcul de la solde auparavant dévolu aux différents SIRH du ministère de la défense. Il devait constituer un point d’étape vers l’ONP. Le calculateur n’étant pas suffisamment éprouvé face à la complexité du système indemnitaire de solde, il génère de nombreuses erreurs de paiement depuis trois ans. Les trop versés continuent de s’accumuler en 2014 : 14 millions dans la Marine, 14 au service de santé des armées, plus une partie des 200 millions cumulés sur 2013/2014 pour l’armée de Terre.

Comme l’indique cet article, Accenture/CGI, Atos/Steria et Sopra viennent de réaliser un démonstration du calculateur qui remplacera l’outil actuel. Le dialogue compétitif de Louvois 2, débuté en début 2014, devrait aboutir à une mise en production courant 2015 pour une bascule complète au plus tôt en 2017. Entre les deux est sensée intervenir une période de paye en double… enfin il faudrait plutôt dire en triple car comparer les pré-liquidations de Louvois 2 à Louvois 1 ne sera pas suffisant. Il faudra faire une passe manuelle étant donné qu’il n’y aura pas de système de référence fiable.

Il faudra également composer avec la fusion concomitante des SI de chaque armée au travers du programme Source (Louvois n’est « que » le calculateur de solde).

Hasard du calendrier, cette démonstration intervient quelques jours après la bascule de la première vague de population dans le nouveau SIRH (SIRHEN) de l’éducation nationale. Après deux phases d’homologation par la DGFiP au printemps (pas totalement dépourvue d’erreurs), la subdivision de la première population migrée en deux sous-vagues et le report d’une montée de version au printemps prochain… l’année probatoire du programme (audit Neoxia/Deloitte) sera-t-elle validée ? SIRHEN sera-il le prochain programme jeté dans l’abîme ?

Et les transformations informatiques sur le plan RH ne sont pas terminées ! Au programme des prochaines années : la conversion iso-fonctionnelle de PAY (conversion semi-automatisée du code COBOL/Pacbase en Java avec BluAge), l’intégration des populations payées dans ETR (agents en poste à l’étranger) dans PAY, l’enrichissement des fichiers retour post-liquidation, la prise en compte du noyau RH-FPE v5, la création d’une base décisionnelle des trois fonctions publiques, le passage à la DSN fonction publique, l’alimentation du RGCU par le service des retraites de l’État…

MAJ 08/12/2014 : comme l’indique l’article Wikipedia relatif à Louvois, ce qui est appelé Louvois 1 ci-dessus est en fait la troisième version de la trajectoire Louvois. Plus de détails sur le programme.

Neutralité des réseaux : stop ou encore ?

NewtImpact nous apprend que le conseil européen version télécom s’est réuni hier à Bruxelles afin de trouver un consensus autour du paquet télécom. Fer de lance du marché unique européen voulu par Neelie Kroes (commissaire au numérique de la précédente législature), les deux principaux sujets de ce règlement sont l’extinction des frais d’itinérance sur le territoire européen au 15 décembre 2015 et la neutralité des réseaux.

La neutralité des réseaux avait tout d’abord été retirée du rapport Castillo-Vera par des amendements de compromis au sein de la commission ITRE le 18 mars puis rétablie par le parlement lors du vote de ce même rapport en plénière à Strasbourg le 3 avril. La position française allait à l’époque à l’encontre de cette garantie de traitement égalitaire des paquets sans discrimination portant sur leur émetteur, leur destinataire ou leur contenu. Concrètement un opérateur de réseau neutre fait payer le consommateur selon la classe de débit (constant) choisie et la quantité de données consommées (avec pourquoi pas d’importants quotas voire un forfait illimité) tout comme le font les fournisseurs d’énergie et dans une moindre mesure d’eau. Ce principe est nécessaire à l’innovation technologique et au maintient des libertés fondamentales sur internet.

Aucun consensus n’a pu être trouvé lors de la réunion d’hier, ce règlement (d’application immédiate, sans transposition) n’est donc pas prêt de passer en seconde lecture au parlement.

La modernisation du système d’information de l’Etat au service de la simplification des usages

Cet article est un compte-rendu de la conférence organisée le 14 novembre 2014 à la Cité de l’innovation publique (au 104) par la DISIC. Attention, j’ai parfois complété le discours par des informations issues d’autres sources ou des réflexions personnelles (FranceConnect en mode dégradé par exemple).

Je suis enthousiaste de la vision portée par la DISIC qui reprend un certain nombre d’idées que j’avais formulées de mon coté dans mes précédents travaux. Les deux plus importantes sont l’exposition systématique par API (seconde partie de mon rapport sur l’innovation et les politiques publiques) et la traçabilité des échanges entre SI publics ou le privacy by design (partie 3.3 de mon mémoire sur l’Évolution d’internet : confiance, identités, vie privée, statut des données et modèles économiques).

Présentation de la DISIC par Jacques Marzin

La DISIC (Direction interministérielle des systèmes d’information de l ‘État) est une structure légère d’une quarantaine de personne rattachée au SGMAP (secrétariat général à la modernisation de l’action publique) auprès du Premier Ministre.

Elle a pour mission de maîtriser la complexité organisationnelle et technique du SI de l’État en vue de rationnaliser ses composantes et d’aider les ministères à sécuriser les opérations de refonte. L’objectif en toile de fond est d’améliorer la relation entre administration et administrés (et notamment l’avènement du cross-canal). Bien que la DISIC n’ait statutairement à charge que le SI de l’État, elle est amenée à travailler avec les trois fonctions publiques, les OPS et autres opérateurs publics ou semi-publics. Il y a unicité juridique du SI de l’État depuis aout 2014.

Concrètement, la DISIC a lancé plusieurs chantiers :

  • Réunion mensuelle des DSI des ministères afin de suivre leurs projets respectifs et de visualiser les interactions entre les différents projets.
  • La mise à jour régulière (en théorie) des référentiels généraux d’accessibilité, de sécurité et d’interopérabilité qui s’imposent à toute structure publique
  • La construction du RIE (réseau interministériel de l’État) et le raccordement des administrations déconcentrées à celui-ci
  • Établir le plan d’occupation des sols du SI de l’État et opérer une rationalisation des infrastructures. L’objectif affiché est de passer de 120 à 20 datacenters d’ici dix ans. Il s’agit notamment de faire monter en puissance la virtualisation afin de construire un cloud pour l’administration.
  • Mutualiser les briques transversales telles que les outils collaboratifs (messagerie et agenda : projet Melanie2) : un ministère porte le service pour les autres. Le préalable est la création d’annuaires communs et de SSO.
  • Promouvoir l’utilisation du logiciel libre que ce soit coté client (Firefox, Thunderbird, LibreOffice…) ou serveur (PostgreSQL, Linux, Tomcat…). Les développements engagés sur fonds publics ont vocation à être reversés aux communautés. Une fraction des coûts de licences économisés devait également être reversée. Coté client, cela passe par une réduction des adhérences des différentes applications métiers au système d’exploitation et aux suites bureautiques par la généralisation des clients n-tiers de type web.
  • Deux projets concrets pour le grand public : Marchés publics simplifiés et Mes aides simplifiées dans le cadre du choc de simplification

Jacques Marzin a insisté sur le fait que la DISIC n’a pas vocation à se substituer aux DSI ministérielles mais de dégager des synergies et d’apporter une cohérence et une vision d’ensemble sur le long terme.

La richesse de l’État français contrairement à d’autres (UK ?) est d’avoir conservé ses 18000 informaticiens. Ceux-ci sont les gardiens de la donnée et des processus de l’État. Il se révèle cependant complexe de trouver une culture commune et de remettre en cause l’indépendance totale des DSI ministérielles.

L’enjeu est de passer d’une logique où il faut « apporter la preuve que la mutualisation est économique et bonne » à une logique où « l’on doit démonter que la mutualisation est anti-économique pour ne pas la faire ». De même, la DISIC souhaite généraliser le Agile first. Outre les réticences culturelles, la difficulté principale de la DISC est la continuité managériale dans le temps : un projet n’est viable que si sa gouvernance reste stable.

 

Présentation des SIDSIC par Eddy Babel

Eddy Babel est membre du SIDSIC (Service interministériel départemental des systèmes d’information et de communication) du Calvados. Son but est de décliner sur le terrain les projets portés par la DISIC.

Eddy Babel a présenté la raison d’être du RIE dans son département ainsi que les étapes de raccordement.

 

État plateforme et identité numérique par Guillaume Blot

Le concept d’État plateforme a été introduit par Nicolas Colin et et Henri Verdier (aujourd’hui CDO de l’État) dans leur livre l’Âge de la multitude où ils le décrivent l’appropriation par la puissance publique de la logique d’API ouvertes mise en œuvre par les géants du web et notamment Amazon. La DISIC considère la donnée publique comme un bien commun.

L’objectif est de concevoir les services publics autours des besoins et des situations des « clients » usagers (cross-canal). Favoriser l’émergence de véritables écosystèmes ouverts à tous les acteurs (publics, associatifs ou privés) pour aller vers un État collaboratif, préalable essentiel à une service public sans couture. Il s’agit également de co-constuire cet État plateforme en mettant en œuvre l’agilité typique des start-ups.

Un pré-requis à l’État plateforme est la capacité d’identifier/authentifier de manière univoque un citoyen et s’interconnecter avec des SI hétérogènes et âgés sans attendre une hypothétique CNIE. La DISIC a donc réuni les DSI des principaux acteurs publics afin de traiter cette question. Certains voulaient perdre 18 mois pour créer un standard franco-français alors que d’autres préféraient utiliser les standards  internationaux existants. Il a été décidé d’utiliser les standards du web tels que JSON, XML, REST/http. Cela permettra une intégration rapide (ordre d’idée : deux heures de développement pour intégrer FacebookConnect).

Cette identification permet a posteriori l’échange de données entre administrations. Ces travaux ont donné lieu à une spécification : FranceConnect.

FranceConnect n’est pas une identité numérique. C’est une architecture permettant de fédérer les identités entre les fournisseurs de services et les fournisseurs d’identité (extension de la spécification LibertyAlliance adaptée par l’ADAE en 2004, socle de mon.service-public.fr NDLR). À ces acteurs s’ajoutent des « hubs » visant à contextualiser l’information transmise par un fournisseur de données à un fournisseur de service. Contextualiser de l’information signifie délivrer au demandeur uniquement l’information dont il a besoin pour traiter son dossier.

Exemple fictif : un père de famille souhaite inscrire son fils en crèche. Il se rend sur le site web de sa mairie et peut se connecter avec n’importe lequel des fournisseurs d’identités implémentant FranceConnect fournissant un niveau d’identification suffisant (faible, moyen ou élevé) comme par exemple son compte CAF ou son compte fiscal. Il peut ensuite remplir sa demande de crèche en ligne et communiquer son numéro fiscal. La mairie pourra alors demander au hub APIkids le revenu du couple nécessaire au traitement de la demande.

Depuis les détournements des fichiers nominatifs sous l’occupation, les français sont attachés à l’indépendance des bases de données administratives. La France a mis en place plusieurs outils institutionnels limitant de telles interconnexions (création de la CNIL quatre ans après le scandale SAFARI) et doit régulièrement revoir ses dispositions d’échange de données (couplage fort des empreintes retoqué par le conseil constitutionnel lors de la création de la CNIE, suppression de champs de BaseElèves…). La réussite de ce projet d’État plateforme est donc politiquement conditionnée aux gages de bonnes fois apportés par cette nouvelle architecture conçue autour du Privacy by design. FranceConnect doit permettre l’échange fluide et dématérialisé des informations dont les organismes ont besoin pour mener à bien leur mission sans jamais leur en fournir d’avantage que ce qu’ils ont actuellement avec un traitement des pièces justificatives papier (ou non structurées).

Le rôle du « hub » est justement de transmettre uniquement les éléments nécessaires au traitement de la demande. Dans notre exemple, la mairie n’aura accès qu’au quotient familial et non plus l’intégralité de l’avis d’imposition. On pourrait également envisager que le hub consolide les données fournies par plusieurs organismes et ne renvoie que « oui » ou « non » à une question type.

FranceConnect renforcera également le droit d’accès à l’information établi par la loi de janvier 1978 puisque toutes les informations échangées seront tracées, traces facilement accessibles au citoyen. D’un point de vu fonctionnel, le citoyen pourra modifier, via une API les dites informations s’il constate qu’elles ne sont pas à jour.

La beauté de cette architecture est donc d’industrialiser les échanges tout en renforçant la qualité des données et fournissant un cadre structurant qui protège le citoyen et lui donne un gage de traçabilité. On pourrait aussi imaginer que les citoyens puissent soit bloquer (opt-out) ces inter-échanges, soit valider manuellement chaque échange ou bien les ralentir automatiquement (accord pour transmission sans action sous deux jours). Dans le premier cas, le citoyen devrait alors fournir la pièce justificative manquante par un mode dégradé et supporter le délai et la complexité associés. Ce mode dégradé pourrait notamment passer par le téléchargement de la pièce justificative au format PDF avec un tag 2D-DOC, reconnue automatiquement par le SI destinataire.

Une question demeure : aurons-nous un identifiant unique ? Si je m’identifie sur un site avec mon compte CAF, puis la fois suivante avec mon compte fiscal, comment le site pourra-t-il me reconnaitre ?

Dans une logique d’ouverture et de réutilisation, la DISIC favorise la publication de code source sur des forges ouvertes telle que celle de l’ADULLACT ou JoinUp (portée par l’UE). Publier sous licence libre constitue un changement conséquent pour les informaticiens de l’État.

Calendrier prévisionnel :

  • Publication de la spécification et appel à commentaires mi-novembre
  • Première implémentation au printemps 2015
  • Migration de mon.service-public.fr fin 2015
  • Intégration de la DGFiP pour la déclaration d’IR 2016

Henri Verdier sera à l’écoute des partenaires pour déterminer les données qu’ils peuvent ou non exposer et comment les exposer.

 

Questions

Aujourd’hui l’utilisation du NIR est très encadré, comment la CNAV être un fournisseur d’identité puisque le login est le NIR ?

Lorsque l’administré sélectionnera l’identification CNAV depuis le site de sa mairie, il sera rediriger vers la page d’identification de la CNAV qui renverra un token d’authentification (sans aucune sémantique), le niveau d’authentification au standard e-IDAS (faible, moyen, fort) et des informations de base sur l’individu (nom et prénom). Le NIR ne sera jamais transmis.

Qui de l’interopérabilité avec les autres pays européens ?

FranceConnect sera le point d’entrée de la fédération d’identité européenne e-DAS coté français. Les fournisseurs d’identité devront être conventionnés avec FranceConnect mais les consommateurs d’identités pourront facilement intégrer FranceConnect. On envisage de promouvoir la plateforme chez des e-commerçants ou des banques françaises. Ces organismes commerciaux n’auront aucun accès aux données privées des citoyens.

Un journaliste : Qui est le porteur de projet, de la gouvernance de FranceConnect ?

La DISIC.

Aurélien Dumaine : Vous parliez de mutualisation des infrastructures des ministères. Ne pourrait-on pas utiliser FranceConnect pour authentifier les agents aux backend des SI ministériels ? La personne physique étant la même, il pourrait y avoir une continuité du vecteur d’identification.

L’architecture pourra être instanciée pour permettre l’authentification des agents aux backends métier mais le vecteur d’authentification ne sera pas le même. Nous souhaitons conserver des fournisseurs d’identités professionnelles distincts.

L’Assemblée accorde une rallonge budgétaire de 8 millions d’euros à la DISIC

Dans la série « volet dépense de la loi de finances 2015 », l’assemblée a doublé le budget prévu pour la DISIC grâce à un amendement proposé au dernier moment par Bercy. Il s’agit de donner les moyens à la DISIC de piloter la transformation vers l’État plateforme passant notamment pas :

* l’orientation WS des nouveaux projets et l’encapsulation des SI legacy dans des API ouvertes qui permet notamment le lancement de « Marchés publics simplifiés », « Aides publiques simplifiées » (les deux premières mesures phares du programme « Dites-le nous une fois » du Choc de Simplification)

* la refonte, extension et décentralisation de la fédération d’identité de MonServicePublic avec la plateforme FranceConnect. Cela permettra aussi la traçabilité des échanges inter-administrations. Quarante ans plus tard, on peut y voir une preuve de bonne fois pour attendrir les détracteurs du projet SAFARI. On pourrait même imaginer offrir un mode dégradé à ceux qui souhaiteraient bloquer ces inter-échanges automatiques (peut-être usine à gaz mais avec des sujets politiques tout devient possible).

La DISIC a également compétence pour chapoter les projets SI importants au niveau de l’État ou de composantes de la sécurité sociale. Elle pilote le plan de raccordement au réseau interministériel de l’État ainsi que la mutualisation des infrastructures.

Chez Octo on doit être en train de sabrer le champagne : les cordons de la bourse s’ouvrent en grand pour eux !

Authentification automatique chez Orange : WTF

Je viens d’arriver dans un gîte pour quelques jours de vacances avec de la famille. Mon oncle en profite donc pour me demander un coup de main : Microsoft lui demande de mettre à jour ses paramètres de sécurité avant d’accéder à sa messagerie Outlook et ça le perturbe. À la création de ce compte, il a saisi son adresse email Orange comme adresse de secours. Je vais donc pour me connecter, depuis mon ordinateur portable personnel, au webmail Orange… et là c’est le drame : je suis connecté sur le compte email du propriétaire du gîte.

Mais c’est quoi ce bordel ?!

Les ingénieurs de chez Orange croient-ils que tous les utilisateurs du réseau de madame Michu ont son entière confiance au point de lui donner accès à ses mails… autant lui livrer le numéro de carte bancaire en même temps, package fidélité ?! Croient-ils qu’elle est consciente de donner accès à toute sa correspondance, ses factures détaillées de téléphone et au moyen de changer tous ses mots de passe lorsque son fils donne le code Wifi à ses potes en soirée (il n’y pas de réseau « invité » distinct sur la Livebox) ? Non mais c’est pas croyable !

Mise à part cette absurdité de sécurité, ça entretien la croyance que la boîte email n’est accessible qu’au domicile chez les personnes les moins à l’aise avec la technologie. D’autre part ça ne les aide pas à retenir leur mot de passe d’adresse email, chose que l’on devrait connaître aussi bien que son code de carte bleue.

En cherchant il s’avère que l’on peut contourner ce comportement par défaut déviant inadmissible. Mais non, contrairement à toute logique il ne s’agit pas d’une case à décocher dans l’espace client ou dans l’interface d’administration de la Livebox, il faut créer une adresse de messagerie « secondaire » sur le compte, même si elle ne servira jamais.

Je pestais à l’automne contre le stockage des mots de passe en clair chez Free, mais là on atteint un niveau record.

J’ai acheté le Hi4G

Après 4 ans de bons et loyaux services mon Samsung Galaxy Spica est devenu difficilement utilisable et sa batterie limite son autonomie à quatre heures en veille. Il me fallait donc un nouveau smartphone avant de partir en vacances. Après avoir recherché sans succès un mobile 4G double SIM et attendu en vain que le OnePlus One soit disponible pour le commun des mortels, j’ai choisi le Hi4G.

Je le conseille à tous ceux qui souhaitent acheter un smartphone pas cher ayant un très bon rapport qualité/prix. C’est en fait un ZTE Blade Apex 2 distribué en France exclusivement par le groupe Orange en marque blanche.

Quelques points à noter :

  • il est compatible 4G catégorie 4 (jusqu’à 150 mbps en réception sur les réseaux compatibles comme Free ou Orange)
  • il possède 1024 Mo de RAM, un écran de 4″5 et un processeur Qualcomm Snapdragon 400 (1,2 GHz Quad-core), 8Go de ROM
  • il possède un port microSDHC pouvant étendre la mémoire morte à 32 Go
  • la batterie ne peut pas s’enlever
  • je n’ai pas encore trouvé de tutoriel pour le rooter

Plus de détails et un test complet sur le site de 01.net.

Ce mobile semble avoir baissé de dix euros depuis son lancement fin avril et coûte aujourd’hui 119€90 tant en boutique que sur le site internet. Sachez que vous n’êtes pas obligé de prendre la Mobicarte(gratuite) qui sera proposée par le vendeur. J’ai acheté le mien seul, sans aucune carte SIM venant de chez Orange.

Point très important : en achetant ce mobile seul ou avec une Mobicarte (ou toute offre « non engageante » Orange), il est possible d’obtenir le code de desimlockage gratuitement et immédiatement après l’achat. Je suis tombé sur un vendeur très sympa bien qu’un peu à coté de la plaque car il n’était pas au courant des procédures de desimlockage de l’opérateur pour lequel il travaille ! C’est pourtant le B.A.BA.

Conformément à la loi Hamon entrée en vigueur en juin, la garantie de conformité est de 24 mois(comme indiqué sur l’étiquette produit en boutique). Pour en bénéficier au-delà des six premiers mois, le consommateur devait auparavant prouver lui-même que le défaut était présent au moment de l’achat. Orange vendant ce téléphone sous sa propre marque, ce sont ses vendeurs qui devront assurer le service après-vente que l’on ait ou pas souscrit un abonnement chez eux.

MAJ du 10 août 2014 : Après vérifications, le dernier paragraphe de mon article comptait un certain nombre d’erreurs :

  • d’après cet article concernant la loi Hamon : Concernant le passage du délai de six mois à deux ans de la garantie légale de conformité, il faudra attendre deux ans après la publication de la loi, soit le 17 mars 2016.
  • l’inscription « SAV 24 mois » sur les étiquettes des produits en boutique Orange n’est valable que si l’on possèdes toujours la ligne Orange qui a été souscrite (ou renouvelée) en même temps que l’achat du mobile
  • le Hi4G est bien vendu sous la marque commerciale Orange mais comme ZTE apparaît bien sur l’étiquette de la boite de l’appareil, c’est ZTE qui est tenu d’assurer le service après vente constructeur en cas de défaut matériel
  • cette garantie constructeur est valable 12 mois pour les produits achetés en juillet 2014
  • pour faire valoir cette garantie constructeur gratuite de 12 mois, on peut renvoyer le produit par colis ou bien aller dans l’une des 170 boutiques PSM (Point Service Mobile) agréées par ZTE

Retour sur le code sprint POS chez Akretion

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

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

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

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

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

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

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

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

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

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

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

Ivre, la FCC parle de neutralité

Depuis le petit arrangement entre Chromecast et Netflix, puis sa validation par la justice américaine, le débat sur la neutralité des réseaux a refait surface aux États-Unis. Je viens de lire un article particulièrement… étrange sur le site ZDNet dans lequel on peut lire :

Le débat sur la neutralité du net enfle depuis plusieurs semaines  à l’approche du 15 mai, date à laquelle la FCC doit s’exprimer sur son nouveau projet de régulation. Face à la mobilisation de nombreux acteurs, le régulateur américain se défend de vouloir remettre en cause la neutralité du réseau.

Dans un nouveau document le président de la FCC, Tom Wheeler, précise ses positions : la FCC entend bien autoriser les FAI à fournir de meilleurs débits aux fournisseurs de services et contenus acceptant de payer l’accès à cette « voie rapide ». La commission ajoute néanmoins qu’elle veillera à ce que ces pratiques ne discriminent pas les entreprises refusant de payer.

La FCC pense qu’autoriser et réguler ce type d’accord est le meilleur moyen de protéger la neutralité du net. Une lettre ouverte, signée par une centaine d’acteurs majeurs du Web et publiée la semaine dernière, montre que cette vision n’est pas partagée par tous.

Soit des subtilités de langage se sont perdues en cours de traduction, soit ces gens de la FCC ont besoin qu’on leur rappelle ce qu’est la neutralité des réseaux. Il est intrinsèquement impossible de réguler la neutralité des réseaux. Par définition, la neutralité est le fait de délivrer des paquets IP sans distinction de l’émetteur, du récepteur ou de leur contenu donc de manière systématique. On ne peut donc aucunement soumettre l’accès à des « voies rapides » à quelconque paiement. C’est totalement absurde.

D’autre part, comment pourrait on assurer que les entreprises refusant ne payer ne soient pas discriminées alors que le but d’un échange marchand est de procurer à un client un bien ou un service qu’on ne lui fournirait pas sans contre-partie financière ?

Hey la FCC, tu t’es vue quand t’as bu ?

Gestion de projet : premier échec.

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

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

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

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

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

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

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

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

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

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

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