Carnet de notes

Auteur/autrice : Éric

  • Impact de la léga­li­sa­tion des échanges non marchands

    Une nouvelle étude vient confor­ter l’idée que la contre­façon de biens imma­té­riels n’a d’im­pact néga­tif ni sur la créa­tion ni sur l’in­dus­trie cultu­relle, au moins concer­nant les échanges non marchands.

    Cette dernière étude nous vient de la Commu­nauté euro­péenne elle-même, en se concen­trant sur la musique. En fait, malgré les décla­ra­tion publiques et poli­tiques, le fond ne fait plus tant débat que ça : L’im­pact lié aux échanges entre parti­cu­liers est au pire peu signi­fi­ca­tif sur le marché global.

    Pour­tant je trouve que certains vont un peu vite dans les inter­pré­ta­tions et conclu­sions :

    Si on consi­dère que la contre­façon n’a que peu d’im­pact globa­le­ment pour l’in­dus­trie, je ne crois pas avoir vu beau­coup de chiffres sur la répar­ti­tion des reve­nus. Il est tout à fait légi­time de penser que si le montant d’achat global n’est pas entamé, il puisse se repor­ter sur d’autres oeuvres ou d’autres types de pres­ta­tion.

    Quel est l’im­pact sur la diver­sité de la créa­tion ? sur la rému­né­ra­tion de certaines caté­go­ries d’ac­teurs écono­miques ? ou plus simple­ment comment cette répar­ti­tion évolue­rait-elle si on ouvrait large­ment les échanges non marchands ?

    Dans le même esprit, les études se basent sur le contexte actuel où les échanges non marchands ont un frein impor­tant du fait de leur illé­ga­lité en soi (très impor­tant pour une grande partie de la popu­la­tion) mais aussi de ce qu’im­plique cette illé­ga­lité au niveau de la visi­bi­lité de l’offre non marchande pour monsieur tout le monde, de la confiance qu’on peut accor­der ou non à ces acteurs non offi­ciels ou non recon­nus, de leur répu­ta­tion, de la peur du gendarme, etc.

    Les résul­tats actuels peuvent-ils vrai­ment être consi­dé­rés comme conti­nus si on légi­time ces échanges non marchands et que les offres corres­pon­dantes passent en concur­rence directe des offres marchandes avec le prix comme seul diffé­rence ou presque ?

    Bref, sauf à avoir manqué des éléments, ces études ne me paraissent pas être un élément perti­nent pour déci­der de la léga­li­sa­tion ou non des échanges non marchands. Ce serait large­ment les sur-inter­pré­ter.

    Je ne tire que deux conclu­sions sur ces études :

    • Il n’est pas légi­time de deman­der des dommages et inté­rêts déme­su­rés aux coupables de ces partages non marchands
    • Inves­tir des sommes déme­su­rées ou aller jusqu’à enta­mer les équi­libres des liber­tés civiles pour frei­ner cette contre­façon n’a aucun sens écono­mique.

    Je garde aussi deux faits essen­tiels qu’il serait dommage d’ou­blier :

    • Rien ne tuera la créa­tion, et surtout pas la capa­cité de chacun d’ac­cé­der et s’ap­pro­prier des conte­nus.
    • Si on n’uti­lise pas l’argent pour ache­ter ces biens cultu­rels, il sera utilisé pour d’autres biens cultu­rels, ou d’autres biens tout court. L’éco­no­mie globale ne tombera pas pour autant.

  • Pauvreté en Alle­magne: un rapport embar­ras­sant pour le gouver­ne­ment

    Je ne saurai trop me battre contre l’idée moderne de prendre exemple sur l’Al­le­magne concer­nant tout ce qui a trait à l’éco­no­mie. Il y a de très bonnes choses à reprendre, mais c’est loin d’être un modèle à reco­pier.

    Les 10% d’Al­le­mands les plus fortu­nés se partagent 53% de la richesse natio­nale. Les 50% les plus pauvres ne possèdent que 1% de la richesse du pays,

    […]

    L’Al­le­magne se porte bien, le chômage recule, insiste ainsi le ministre accusé d’avoir cher­ché à enjo­li­ver les pages du rapport consa­crées à la pauvreté. Pour l’as­so­cia­tion Cari­tas, les chiffres présen­tés mercredi sont alar­mants, du fait notam­ment de l’ab­sence d’as­cen­seur social dans le pays.

    Bref, juste ne pas oublier que l’objec­tif c’est les gens, pas l’éco­no­mie. Si pour l’éco­no­mie il faut augmen­ter la pauvreté, des jobs à 1 € et une répar­ti­tion des richesses défaillantes, peut être se four­voie-t-on quelque part en chemin.

  • Graphiques à affi­cher – Flotr2

    Il y a long­temps j’uti­li­sais jpgraph puis arti­chow en PHP pour géné­rer toutes sortes de courbes ou camem­berts. Un peu après j’uti­li­sais beau­coup les API google chart, avec pour bonne valeur ajou­tée de ne plus faire de trai­te­ment sur mes serveurs. Le anno­ta­ted time­line est d’ailleurs encore un modèle du genre avec ses anno­ta­tions et ses possi­bi­li­tés de zoom par période.

    J’ai testé plusieurs biblio­thèques javas­cript plus ou moins inté­res­santes mais je suis retombé sur Flotr2 qui génère des images assez lèchées. Pour de l’ap­pli­ca­tif complexe les fonc­tion­na­li­tés de google chart restent avec peu d’équi­valent, mais pour 80% des besoins courants, ça fait le job, et plutôt très bien.

    Vous avez quoi en stock de votre côté pour géné­rer des info­gra­phies de données ?

  • We’re not ‘appy. Not ‘appy at all.

    Les services numé­riques du gouver­ne­ment UK ont mis en ligne un long billet sur leur réponse à la problé­ma­tique « mobile ». On y voit un vrai travail pour donner accès aux appa­reils mobiles, avec des résul­tats spec­ta­cu­laires. Passer de 0 à 45% d’uti­li­sa­teurs mobiles en un an, ça montre que la demande est là.

    Le point inté­res­sant est décrit à partir du support de présen­ta­tion, c’est la poli­tique « no (native) apps ». Ils ont fait du web mobile, et y ont réussi. C’est défi­ni­ti­ve­ment la voie à privi­lé­gier, l’ap­pli­ca­tion étant à réser­ver à des usages spéci­fiques excep­tion­nels, et seule­ment après avoir assuré l’as­pect web.

    Une direc­tion à s’ap­pro­prier et à parta­ger.

  • Petit guide de typo­gra­phie française à l’usage de Mac OS X

    Pour publier les raccour­cis plus ou moins bien connus :

    • Les majus­cules de É, È, Ç et À se trouvent sur les même touches que les minus­cules, il faut juste avoir activé les majus­cules (pas avec le shift, qui donne­rait des chiffres, mais avec le caps lock). Je ne crois pas qu’il existe d’autres lettres accen­tuées qui devraient se retrou­ver en majus­cules nati­ve­ment mais n’hé­si­tez pas à m’en signa­ler.
    • Les guille­mets typo­gra­phiques à la française se trouvent sur le 7 avec option pour l’ou­vrant « et shift+op­tion pour le fermant ». Les guille­mets de second niveau ‹ et › sont eux sur le w avec les mêmes combi­nai­sons mais ses dernières conflictent parfois avec des raccour­cis appli­ca­tifs. Si vous citez de l’an­glais, les guille­mets “ ”et apos­trophes anglaises ‘ ’ sont simple­ment posi­tion­nés sur le guille­met et l’apos­trophe droits, donc sont plus simples à trou­ver. J’avoue que j’uti­lise le guille­met simple anglais fermant pour l’apos­trophe typo­gra­phique française ’ ; je crains que ce ne soit une erreur mais je n’ai pas trouvé de combi­nai­son plus adéquate.
    •  Les æ et œ se trouvent respec­ti­ve­ment sur le a et sur le o en combi­nai­son avec la touche option, vous pouvez ajou­ter le shift pour la majus­cule.
    • Les points de suspen­sions … sont sur la même touche que le point, avec la touche option acti­vée. Le point de puce de liste • est sur la même posi­tion avec shift en plus. Il y a aussi un point simple en milieu de ligne · qu’on peut trou­ver sur option+­shift avec la touche f.
    • Les quadra­tins — et demi quadra­tins – se trouvent sur la touche du trait-d’union – en acti­vant la touche option, cumu­lée à la touche shift dans le second cas.
    • Oh, et l’es­pace insé­cable fine est bien entendu sur option + espace. Atten­tion, certains logi­ciels conver­tissent tout seuls en espace simple.

    Dans l’en­semble c’est assez natu­rel avec option et shift+op­tion mais j’avoue ne jamais retrou­ver les guille­mets.

     

  • Distri­buons l’aide à la presse direc­te­ment aux jour­na­listes!

    Autant le revenu de base fait écho chez moi sur plusieurs points, autant il repose sur un prin­cipe fonda­men­tal : S’ap­pliquer à tous, sans condi­tion, sans diffé­rence.

    En imagi­nant un revenu mini­mum en distri­buant l’aide à la presse direc­te­ment aux jour­na­listes, qui décide qui est jour­na­liste ? La ques­tion se pose déjà mais avec un enjeu qui n’a aucune mesure avec celui qui pour­rait nous attendre. Souhaite-t-on vrai­ment des jour­na­listes d’État payés par ce dernier ? Le risque me parait énorme, surtout pour une profes­sion qui parle tant d’in­dé­pen­dance et qui est déjà tant sous le jeu de pres­sions externes.

    Et puis pourquoi les jour­na­listes ? Pourquoi pas aussi les taxis ? les ramo­neurs ? les agents de sécu­rité ? les avocats ? Toutes les profes­sions sont utiles et indis­pen­sables. Nombreuses sont celles qui peuvent prétendre avoir des diffi­cul­tés, et souvent avec moins d’aides que n’en ont les jour­na­listes. Ces derniers ont d’ailleurs direc­te­ment des statuts parti­cu­liers, entre autres sur la fisca­lité. Sous quel prétexte donne­rait-on encore un avan­tage caté­go­riel à X ou Y dans une période où tous sont sur le fil et où nous savons avoir déjà trop d’avan­tages parti­cu­liers ?

  • Défi­nir son API : version­ne­ment

    Toujours dans la logique de réflé­chir son API, parce qu’un jour il faudra la faire évoluer, comment gérer le version­ne­ment ?

    Plusieurs solu­tions ont émergé :

    • https://api-v2.example.com/mares­source
    • https://api.example.com/v2/mares­source
    • https://api.example.com/mares­source-v2
    • https://api.example.com/mares­source?v=2
    • https://api.example.com/mares­source avec une entête Version: 2
    • https://api.example.com/mares­source avec une entête Accept ou/et Content-type: appli­ca­tion/monfor­mat;version=2

    La solu­tion du sous-domaine n’est à mon sens à réser­ver que pour les big-bang. Elle n’est pas faci­le­ment multi­pliable à l’in­fini, mais à l’avan­tage de permettre aisé­ment d’avoir même deux plate­formes tota­le­ment sépa­rées pour les deux versions de l’API.

    Les deux suivantes se distinguent par le fait de version­ner l’API ou la ressource. J’ai tendance à penser que s’il faut version­ner la ressource en cassant la compa­ti­bi­lité, alors c’est peut être une nouvelle version de l’API qui est à publier si on ne veut pas finir avec un gros patch­work diffi­cile à main­te­nir : En gardant tout sous le même espace on s’in­ter­dit de faci­le­ment rendre obso­lète les anciennes versions.

    Quitte à parfois devoir version­ner au niveau de la ressource, l’idée d’ajou­ter un para­mètre a fini par me sembler plus propre. Il s’agit quasi­ment toujours de s’adres­ser à une repré­sen­ta­tion diffé­rente de la ressource, pas de chan­ger son sens fonda­men­tal. Le risque est que la plupart des gens conti­nuent à utili­ser la version d’ori­gine et ne pas prendre en compte le para­mètre. Rendre obso­lète des anciennes repré­sen­ta­tions risque là aussi d’être diffi­cile.

    Les possi­bi­li­tés d’ajou­ter les versions dans les entêtes sont souvent conseillées d’un point de vue théo­rique. En pratique mon retour est que c’est complexe à utili­ser, et d’une valeur ajou­tée assez discu­table. On oublie trop faci­le­ment que le bon usage de l’API tient direc­te­ment à sa simpli­cité et sa bonne compré­hen­sion. S’il y a besoin d’être expert en archi­tec­ture web pour comprendre le pourquoi des choses, c’est une mauvaise solu­tion. Le « tout dans l’URL » ajoute une faci­lité pour tester et échan­ger entre tech­ni­ciens qui vaut toutes les posi­tions acadé­miques du monde.

    Twilio a aussi une façon inté­res­sante de gérer les versions. Au lieu d’un v2 ou v3, le déve­lop­peur indique une date et c’est le serveur qui sélec­tionne la version de l’API à utili­ser en fonc­tion de la date. C’est tentant, souple, mais j’ai peur que ce ne soit pas suffi­sam­ment expli­cite sur ce qu’on utilise ou sur comment gérer ce para­mètre. Qu’est-ce qui change si je met à jour la date ?

    Des lectures et expé­riences je tire quelques recom­man­da­tions :

    • Prévoir dès le départ un système de version­ne­ment, vous en aurez besoin un jour, ne croyez pas que vos API pour­ront rester telles quelles ad vitam eter­nam
    • Impo­ser un version­ne­ment expli­cite, immé­dia­te­ment, dès la première version. Vous évite­rez les ambi­guï­tés et une partie des moules qui s’at­tachent aux adresses « sans version » par défaut
    • N’uti­li­ser que des numé­ros de version simples, pas de notion de mineur/majeur, pas de points ou virgules : Si ça change de façon non compa­tible c’est une nouvelle version et on incré­mente d’une unité. Le reste c’est du marke­ting et ça n’a rien à faire dans vos URLs.
    • Utili­ser un version­ne­ment dans l’URL, à la racine du service ; il sera temps d’uti­li­ser un autre sous-domaine si un jour il y a un vrai big bang qui le néces­site
    • Docu­men­ter (oui, c’est évident, mais pas si simple à ne pas oublier)

  • Défi­nir son API : authen­ti­fi­ca­tion

    Je lis le PDF gratuit de Apigee à propos du design des API web. Si les autres PDF gratuits du site sont assez creux, celui là pose de bonnes ques­tions qui font écho avec mes propres reflexions.

    Je le prends dans le désordre et pour reprendre mes erreurs passées ou celles que j’ai vu chez les autres :

    • Pas de système de session avec point d’en­trée spéci­fique pour le login. Ça demande au client de se préoc­cu­per de l’ex­pi­ra­tion de la session et de son main­tient. Pour des appels isolés ça veut dire faire deux requêtes (login + action) au lieu d’une, avec un délai de réponse finale allongé et une charge plus impor­tante pour le serveur. Sauf besoin spéci­fique, il faut rester en state­less : Chaque connexion contient ses propres infor­ma­tions d’au­then­ti­fi­ca­tion.
    • Pas d’au­then­ti­fi­ca­tion par IP, comme je le vois trop souvent. Outre que c’est un poten­tiel problème de sécu­rité, c’est juste quelque chose de diffi­ci­le­ment main­te­nable et c’est toujours au dernier moment quand on veut faire un correc­tif, une migra­tion ou une bascule vers le serveur de secours en urgence qu’on se rend compte du problème.
    • L’au­then­ti­fi­ca­tion HTTP Digest me semble être une mauvaise réponse à tous les problèmes. Pour amélio­rer légè­re­ment la résis­tance aux inter­cep­tions, il faut stocker le mot de passe en clair côté serveur. Une authen­ti­fi­ca­tion HTTP Basic avec du TLS pour sécu­ri­ser la commu­ni­ca­tion me semble bien plus perti­nent, et aussi plus simple à réali­ser.
    • Le système fait maison est toujours la pire solu­tion, même si vous pensez savoir ce que vous faites. C’est un NO GO commun à toute problé­ma­tique qui touche la sécu­rité. Vous avez plus de chances de vous tirer une balle dans le pied qu’autre chose, et pour le même prix ce sera toujours plus complexe quand vous commu­nique­rez avec des tiers.
    • OAuth 2 a la mauvaise idée d’être plus une boite à outils qu’une solu­tion finie. Même les gros groupes se prennent les pieds dans le tapis avec ça. On rejoint un peu le système fait maison. OAuth a ses défauts, mais globa­le­ment est une sphère contrô­lée que vous devriez préfé­rer.

    Au final il reste le choix entre l’au­then­ti­fi­ca­tion HTTP Basic, l’au­then­ti­fi­ca­tion par certi­fi­cat client avec SSL/TLS, ou OAuth 1.0. Ma grille de choix est la suivante :

    • OAuth s’il s’agit d’avoir une authen­ti­fi­ca­tion à trois pattes. Hors de ques­tion d’im­po­ser à l’uti­li­sa­teur final de saisir ses mots de passes dans un logi­ciel tiers. Pour une API qui veut créer un écosys­tème de logi­ciels clients (type twit­ter) c’est le choix quasi­ment imposé. Oui il y a des diffi­cul­tés pour le mobile ou pour ce qui n’est pas « navi­ga­teur », mais ces ques­tions sont désor­mais large­ment docu­men­tées. Pensez bien que choi­sir ce type d’au­then­ti­fi­ca­tion demande un réel travail (par exemple trou­ver l’er­go­no­mie pour permettre à l’uti­li­sa­teur d’au­to­ri­ser et reti­rer l’au­to­ri­sa­tion d’ap­pli­ca­tions tierces sur votre propre système)
    • HTTP Basic par défaut pour quasi­ment toutes les autres situa­tions. C’est simple côté client, simple et maitrisé côté serveur, supporté partout et pour tout, suffi­sam­ment sécu­risé si on passe par du SSL/TLS.
    • Et les certi­fi­cats clients avec SSL/TLS ? C’est une solu­tion qui semble plus inté­res­sante que l’au­then­ti­fi­ca­tion HTTP mais qui se révèle complexe pour pas mal d’in­ter­lo­cu­teurs. La valeur ajou­tée ne semble pas valoir la complexité supplé­men­taire si vous n’in­te­ra­gis­sez pas avec des entre­prises de taille signi­fi­ca­tive. J’y croyais beau­coup, mais fina­le­ment j’ai peu d’ar­gu­ment face à la simpli­cité du HTTP Basic.

    Et vous ? vous utili­sez quoi pour l’au­then­ti­fi­ca­tion de vos services ?

  • Trajet boulot dodo

    J’ai l’im­mense chance d’ha­bi­ter près de mon job, 20 minutes à pied. Pour contre-balan­cer je suis aussi un grand fainéant. Je cherche donc à éviter cette marche à pied de 40 minutes aller-retour, soit pour la réduire en temps de trajet soit pour la rendre plus confor­table.

    Je prends souvent le tram sur deux arrêts, mais ça me laisse encore 10 grosses minutes à pied et plusieurs minutes d’at­tente. C’est plus par parce que je n’ai toujours pas rési­lié mon abon­ne­ment de trans­port en commun. Je ne gagne pas signi­fi­ca­ti­ve­ment en temps de trajet total et ça n’a d’in­té­rêt que parce que je suis assis un peu plus au chaud. Sauf très forte pluie, ça ne se justi­fie pas vrai­ment et même ma fainéan­tise ne sera pas assez forte pour que je consi­dère ça comme une solu­tion.

    L’idéal pour ce type de trajet serait une bonne trot­ti­nette mais j’ai aussi une belle pente sur la moitié du trajet. Ce n’est pas énorme, dans les 5% au jugé, mais assez pour rendre la trot­ti­nette trop peu pratique.

    Reste le vélo mais mon côté fainéant reprend le dessus consi­dé­rant la pente à 5% (la montée se ferait le soir, quand je suis crevé). Du coup je regarde l’as­sis­tance élec­trique. Ça coûte cher, surtout si je ne l’uti­lise pas tous les jours (le vélo sous la pluie ne m’at­tire pas), donc j’ai un peu de mal à vrai­ment l’en­vi­sa­ger.

    Vous voyez un autre moyen de trans­port à envi­sa­ger ? Avez-vous des recom­man­da­tions ?

  • Adieu SSII, bonjour ESN !

    Est-ce qu’un chan­ge­ment de nom de SSII vers ESN va suffire à faire oublier leur répu­ta­tion sulfu­reuse (et souvent méri­tée) ? C’est pour­tant pour moi la seule moti­va­tion crédible à cette propo­si­tion. Je doute que « service numé­rique » soit signi­fi­ca­ti­ve­ment plus perti­nent, ou que la valeur ajou­tée renta­bi­li­sait le chan­ge­ment de nom.

    Bref, c’est unique­ment du marke­ting et le Syntec ferait mieux de faire évoluer les pratiques que de chan­ger l’em­bal­lage.

    Au moins nous avons évité l’ESD : l’en­tre­prise de services digi­taux. Je ne comprends toujours pas comment on peut faire confiance à toutes ses agences qui se disent expertes du web et du numé­rique et qui pour­tant ne se rendent même pas compte qu’elles utilisent le terme « digi­tal » de travers.