Carnet de notes

Auteur/autrice : Éric

  • Quand EDF fait de l’op­ti­mi­sa­tion fiscale aux Pays-Bas

    Des effets de la gestion par objec­tif des diffé­rentes enti­tés, sans vue et coor­di­na­tion globale : Des socié­tés françaises appar­te­nant majo­ri­tai­re­ment à l’État crééent des filiales à l’étran­ger pour inves­tir afin de payer moins d’im­pôt en France.

    Je ne sais pas si vous notez mais quand EDF paye des impôts, dans les faits ce sont des sous déjà déte­nus indi­rec­te­ment à l’État qui sont trans­fé­rés dans une autre caisse. Faire une filiale à l’étran­ger pour payer moins d’im­pôt c’est trans­fe­rer des sous déte­nus indi­rec­te­ment par l’État français, pour les donner à un état étran­ger. On en trans­fère peut être moins, ça remplit mieux les objec­tifs de tel ou tel comité de direc­tion, mais c’est une perte sèche au final.

    On peut m’ex­pliquer comment l’État gère ses actifs ? Parce que là on marche sur la tête.

    On en parle aussi à propos de la BNF. L’in­té­res­se­ment des direc­teurs à leur struc­ture sans tenir compte de l’in­té­rêt global mène forcé­ment à ce type de compor­te­ment à tous les éche­lons

  • Secure headers

    Secu­re­hea­ders, une gem ruby pour ajou­ter et confi­gu­rer des entêtes liées à la sécu­rité sur vos appli­ca­tions web.

    Et vous, quelles entêtes ajou­tez vous à vos sites pour gérer la sécu­rité ?

  • À Davos, une finance « intou­chable »

    De notre inca­pa­cité à chan­ger une partie du système que l’on sait fonc­tion­ner à l’in­verse du bien commun mais qui surtout met régu­liè­re­ment à risque tout le reste : À Davos, une finance « intou­chable ».

    « Vous pour­riez chan­ger les noms, mais cette histoire d’in­té­rêt person­nel, d’ac­ci­dent imprévu sur les marchés et de pertes massives ressemble à presque toutes les autres catas­trophes finan­cières de ces deux dernières décen­nies. » Comme disent les Anglo-Saxons, « The more things change, the more they stay the same » (« Plus ça change, plus c’est la même chose »).

     

  • Conver­gence web et appli­ca­tion – Stockage Safari mobil / iOS

    Les API qui arrivent sur nos navi­ga­teurs depuis quelques années commence à nous faire imagi­ner une vraie conver­gence entre les appli­ca­tions mobiles et le web.

    C’est déjà un premier pas énorme qu’on voit avec Chrome web store, Fire­fox Market­place, et autres Windows 8 : On commence à déve­lop­per direc­te­ment avec les tech­no­lo­gies web, éven­tuel­le­ment direc­te­ment avec le navi­ga­teur comme plate­forme.

    Main­te­nant pour moi ce n’est pas encore ça. J’ai quelques problèmes côté sécu­rité par exemple (théo­rique­ment entre l’at­tri­but sand­box, l’api postMes­sage et les décla­ra­tions CSP on devrait arri­ver à avoir une bonne base, mais ça n’a pas l’air de coller si faci­le­ment si ce n’est pas bien prévu dès le départ).

    Le butoir sérieux est côté iOS avec son stockage de 50 Mo maxi­mum. Ça peut sembler beau­coup mais c’est fina­le­ment très réduit dès qu’on y stocke autre chose que du pur texte à lire. J’ai réel­le­ment besoin de dépas­ser ce palier. Je paye une bière à celui qui me trouve un méca­nisme qui tourne effi­ca­ce­ment et qui permet de s’en affran­chir sur Safari mobile. Plusieurs bières même. Il peut même y avoir un job ou une mission à la clef pour des bon bidouilleurs javas­cript. Avis aux inté­res­sés.

  • Direc­teur artis­tique, je pouffe

    Chris­tophe nous propose une petite mise à plat sur le terme de direc­teur artis­tique qui fait un peu polé­mique. Il faut y lire direc­teur dans le sens « donner la direc­tion » et artis­tique dans le sens cultu­rel, contex­tuel et émotion­nel.

    Je n’ai aucun problème avec l’ex­pli­ca­tion, mais ça n’en fait pas un bon terme : Ce terme est mal compris, mal perçu, et est même parfois utilisé pour abuser l’in­ter­lo­cu­teur.

    Si on ne comprend rien à ce terme, c’est qu’il faut le chan­ger.

    Alors, oui, je ne comprend peut être pas non plus le tech­ni­cien en charge des examens non-destruc­tifs, mais je n’en suis pas la cible. Je peux suppo­ser que le terme est compris et perçu correc­te­ment dans l’in­dus­trie nucléaire. Force est de consta­ter que le terme de direc­teur artis­tique est mal compris ou mal perçu par beau­coup de gens du web, clients ou colla­bo­ra­teurs. Et ça ça fait une grosse diffé­rence.

    Une partie du rôle de ce direc­teur artis­tique est d’adap­ter le design et l’in­ter­face pour que le message soit compris et que l’uti­li­sa­tion soit effi­cace. Si le design ou l’in­ter­face ne sont pas compris ou mal perçu, alors le travail est mal fait, tout simple­ment. Le direc­teur artis­tique qui dirait que son travail est bon, que c’est juste l’uti­li­sa­teur qui ne comprend rien, que ce dernier manque de curio­sité et qu’il faut l’éduquer… n’a simple­ment rien compris à son métier. Alors pourquoi l’ad­mettre sur son titre lui-même ? Désolé ça n’a aucun sens pour moi comme argu­men­ta­tion.

    Là le terme reste pour des ques­tions d’égo ou de vente alors qu’il ne sert pas la fonc­tion. C’est tota­le­ment insensé.

    Direc­teur artis­tique « junior », je pouffe.

    Oui, je pouffe. Je comprends l’idée que dans tout métier il y a des juniors et des seniors. Je suis même de ceux, rares, qui consi­dèrent qu’il peut y avoir des chefs de projets junior, et même des chefs de projet stagiaires. Pour­tant là je ne pouffe pas, contrai­re­ment au direc­teur artis­tique.

    Qu’on le veuille ou non, la notion de direc­teur induit la conno­ta­tion de direc­tion dans le sens gestion / mana­ge­ment. Certaines agences jouent et abusent même de cette ambi­guité quand elles vendent un direc­teur artis­tique ou quand elles proposent des postes à des junior.

    Parlons des déve­lop­peurs qui sont nommés en fin de billet juste­ment. Nombre d’entre eux sont aussi là pour « donner une direc­tion ». Pour­tant aucun d’entre eux ne se nommera « direc­teur front-end » ou « direc­teur tech­nique » (et encore moins « direc­teur * junior ») sans avoir un poste de direc­tion au sens gestion / mana­ge­ment.

    Le direc­teur artis­tique est à ma connais­sance le seul à le faire, et à ma connais­sance je dirai même que c’est exacerbé en France et limité au web : Dans un spec­tacle le direc­teur artis­tique a toujours un rôle de haut niveau au niveau de la prise de déci­sion.

    Les déve­lop­peurs il y en a des juniors, des seniors, des experts, mais ils sont déve­lop­peurs, éven­tuel­le­ment archi­tectes. On ne me reti­rera pas que nombre de direc­teurs artis­tiques sont des illus­tra­teurs, graphistes, inter­ac­tion desi­gner, éven­tuel­le­ment artistes (au sens créa­tion artis­tiques), ergo­nomes ou plein d’autres choses (souvent plusieurs) qui sont bien plus signi­fi­ca­tives que ce mauvais terme de direc­teur artis­tique.

    Alors ?

    Mais pourquoi donc il y a-t-il tant d’at­ta­che­ment à un nom de fonc­tion qu’il est si mal compris et mal perçu par les tiers ? Il va être diffi­cile de me convaincre que ce n’est pas une ques­tion d’égo pour une partie des DA et une ques­tion de abuser le client pour une partie des agences.

    Effi­ca­cité : Si ce n’est pas ce qui fonc­tionne, chan­geons, même si on pense avoir « raison » acadé­mique­ment. Je ne peux pas penser une seconde que les DA ne connaissent pas ce prin­cipe. Ce devrait même être à la base de leur métier.

  • Sur le dos de Google, les majors musi­cales rejoignent la presse

    Forcé­ment, à imagi­ner des taxes sans fonde­ment et des droits à rente pour des caté­go­ries spéci­fiques, ça créé des envieux. La presse et la musique ont tenté de taxer les four­nis­seurs d’ac­cès Inter­net, mais Google étant le grand méchant du moment, c’est beau­coup plus simple, et puis il n’est pas français.

    La musique veut elle aussi béné­fi­cier de l’ins­tau­ra­tion d’une taxe Google. Telle est le message déli­vré jeudi 17 janvier par Pascal Nègre, président d’Uni­ver­sal Music pour la France, l’Ita­lie, le Moyen Orient et l’Afrique.

    En ayant ouvert la porte à la presse, quelle légi­ti­mité à dire non à l’in­dus­trie musi­cale ? Nos poli­tiques ne se rendent pas compte des impacts à long terme de ce type de bêtise.

  • Fuku­shima, encore une

    A Fuku­shima, selon le même dossier, «  une zone rouge de 20 km a été déli­mi­tée, dans laquelle le gouver­ne­ment travaille à la dépol­lu­tion : nul ne sait quand les quelque 110 000 habi­tants seront auto­ri­sés à rentrer », sans que soit fait mention des vastes zones inha­bi­tables situées à 40 km de la centrale et bien au-delà, et sans que soit rappelé que le critère de défi­ni­tion de la zone de migra­tion obli­ga­toire a été fixé à une dose de 20 milli­sie­verts par an, soit quatre fois plus qu’à Tcher­no­byl et vingt fois la norme inter­na­tio­nale d’inac­cep­ta­bi­lité.

    Bien entendu, sur ce genre de sujets polé­miques, il faut toujours penser à utili­ser son sens critique. Certaines infor­ma­tions en appa­rence scan­da­leuses peuvent se révé­ler fausses ou simple­ment tout à fait légi­times. Tout de même, il faut conti­nuer à lire sans reje­ter par prin­cipe non plus.

  • Fuku­shima, ça existe encore

    Un pois­son pêché à des fins de contrôle près de la centrale nucléaire acci­den­tée de Fuku­shima présente un niveau impres­sion­nant de conta­mi­na­tion radio­ac­tive, plus de 2 500 fois supé­rieur à la limite légale fixée par le Japon, a annoncé, vendredi 18 janvier, l’opé­ra­teur du site.

    Nous sommes à presque deux ans de l’ac­ci­dent, et il ne faut pas oublier que la faune ne reste pas toujours sage­ment aux alen­tours de la centrale. Bref, il ne faut pas toujours donner la voix aux alar­mistes, mais pas toujours non plus à ceux qui refusent de voir toute gravité.

    Ne pas oublier non plus que les limites légales au Japon ont été *très* forte­ment rele­vées, bien au delà des seuils inter­na­tio­naux habi­tuels.

  • Frame­work js pour appli­ca­tion web

    Je regarde un peu les frame­works JS pour « appli­ca­tions dans le navi­ga­teur ».

    Plus j’avance plus je me dis qu’a­vec l’ap­proche mobile et la gestion du offline, on aban­donne le web tel que je le connais­sais. Même avec une foul­ti­tude de javas­cript et d’ajax, nous avons long­temps gardé l’ap­proche « vue sur le client, appli­ca­tion sur le serveur », et j’en ai été un grand défen­seur. Aujourd’­hui l’idée c’est plutôt « appli­ca­tion sur le navi­ga­teur, API sur le serveur ».

    La démarche n’est pas neuve en infor­ma­tique et le milieu a déjà subit plusieurs aller-retour entre les modes « appli­ca­tion sur le client », « appli­ca­tion sur le client synchro­ni­sée avec un serveur », et « appli­ca­tion sur le serveur, vue sur le client ». Il s’agit juste d’un de ces mouve­ments mais côté appli­ca­tions web.

    J’ai regardé quelques frame­works, nommé­ment Back­bo­neJS, Angu­larJS et EmberJS, plus quelques compa­ra­tifs plus éten­dus. Pour l’ins­tant j’ai l’im­pres­sion qu’ils proposent surtout une notion de MVC, avec éven­tuel­le­ment un système de rendu avec liai­son directe entre la partie modèle et la partie contrô­leur.

    Je peux me leur­rer sur la complexité ou sur la valeur ajou­tée en main­te­nance mais j’ai l’im­pres­sion que ça ne sera pas mes points d’at­ten­tion. Orga­ni­ser mes classes je le ferai certai­ne­ment moins bien si je prends tout de zéro, mais ce ne sera pas ma diffi­culté prin­ci­pale. Les liai­sons directes entre vue et modèle ne me semblent pas non plus forcé­ment indis­pen­sable, ça peut même être contre­pro­duc­tif vue la perte de perfor­mance.

    Par contre j’ai besoin de quelque chose pour gérer le côté appli­ca­tif :

    1. M’abs­traire des diffé­rentes solu­tions de stockage client, si possible en gérant les quotas, en ayant un méca­nisme quand on se rend compte que ce stockage a été écrasé et néces­site d’être recréé, etc. Dans l’idéal quelque chose qui ne se contente pas d’être un simple wrap­per et qui sait faire la diffé­rence entre des préfé­rences et de gros conte­nus par exemple, en me propo­sant des solu­tions diffé­rentes pour les deux cas en fonc­tion de ce qui est dispo­nible sur le navi­ga­teur (on n’uti­lise pas les API File et le local storage dans les mêmes contextes)
    2. Avoir en ligne de vue le fonc­tion­ne­ment hors ligne, avec un vrai méca­nisme de mise à jour de l’ap­pli­ca­tion, un vrai méca­nisme de mise à jour des données (synchro­ni­ser dans les deux sens, un premier méca­nisme de conflit ou de prio­ri­sa­tion en cas de conflit), des notions de « à exécu­ter plus tard une fois en ligne », etc. La ques­tion du login est aussi impor­tante (jeton tempo­raire ou perma­nent, quelle sécu­rité, etc.)
    3. Un méca­nisme complet de gestion des URL à base de popS­tate et pushS­tate de façon à ne pas avoir qu’un seul lien vers la page d’ac­cueil mais pouvoir gérer le bouton retour arrière du navi­ga­teur, les favo­ris, les liens entrants, etc. Bref, si je regarde un contenu parti­cu­lier je dois avoir une URL spéci­fique, que je peux copier, trans­mettre, utili­ser. Et par pitié oubliez les #!. C’est aussi plus diffi­cile qu’il n’y parait dès qu’on fait inter­agir ça avec le mode offline.
    4. * Une gestion de base pour les conte­nus. Si on stocke hors ligne, j’ai­me­rai avoir à jouer le moins possible moi-même avec les data:uri, et pouvoir réfé­ren­cer des images ou des conte­nus dans mes vues, à partir de choses stockées hors ligne dans un local­sto­rage, indexdb ou équi­valent
    5. C’est annexe et peut être non relié, mais si possible un jeu de widget ou templates par défaut qui s’adaptent aux diffé­rents contextes de navi­ga­tion (android, ios, win8, la manière dont on présente les listes, les menus, les retours arrière, ne sont pas les mêmes)

    Vous avez quoi pour gérer ces aspects parti­cu­liers ? Parce que pour dessi­ner des pages à partir de modèles et vues OK, mais pour gérer une appli­ca­tion j’ai l’im­pres­sion d’être sans rien.

    Oh, et en plus vu qu’il s’agit d’être multi-device, je ne souhaite pas quelque chose qui rame sur smart­phone. Par contre j’ac­cepte de coder beau­coup de choses à la main, je ne cherche pas forcé­ment un truc qui fasse le café. Même 4 ou 5 petites lib qui s’oc­cupent de leur partie spéci­fique, ça me va.

  • Le jour où les bisou­nours mordront les vautours

    Le sujet du billet lui-même est vaste, et je n’ai pas forcé­ment de valeur ajou­tée à en parler ici, mais le titre lui-même m’in­ter­pelle. Il est réuti­li­sable dans plus d’un contexte, et je crois qu’il reflète très bien mon état d’es­prit fréquent.

    Le jour où les bisou­nours mordront les vautours … à force d’ex­cès, n’est peut être pas si loin.