Carnet de notes

Catégorie : Technique

  • Le web ouvert recule

    On se garga­rise de HTML 5 ou CSS 3, on idéa­lise Wiki­pe­dia et Crea­tive Commons, mais côté web ouvert soyons clairs : Nous recu­lons, et à marche forcée. Ça devient d’au­tant plus préoc­cu­pant que même les plus geeks ne font plus que des décla­ra­tions de prin­cipe sur le sujet, sans le soute­nir par des actions et réali­sa­tions.

    En quelques jours DailyMo­tion aban­donne OpenID, Google lance Google+ et TweetDeck aban­donne son support pour StatusNet. Même les projets libres ne font plus que le mini­mum syndi­cal de ce côté là. C’est une tendance de fond, sous prétexte de simpli­fi­ca­tion de l’ex­pé­rience utili­sa­teur.

    Ce n’est pas un problème de geek

    Je ne suis pas d’ac­cord avec ceux qui prétendent que c’est un problème de geek. Ces préoc­cu­pa­tions sont déjà à l’es­prit des utili­sa­teurs « non experts » :

    • Suis-je obligé de rester si je ne veux pas perdre mes données, mon adresse ou mes connexions ?
    • Puis-je commu­niquer avec des personnes sur des services tiers ?
    • Pourquoi ai-je besoin de gérer 15 iden­ti­fiants avec des mots de passe diffé­rents ?
    • C’est quand même gênant que ce site en sache autant sur moi, non ?
    • Non, ça ne me plait pas mais bon, je n’ai pas le choix, si ?

    Parlez en autour de vous, vous verrez que la plupart des gens ont bien ces problèmes à l’es­prit. Certains ont même déjà des expé­riences doulou­reuses de chan­ge­ment d’adresse (email du FAI), de commu­niquer avec des rela­tions qui sont sur deux plate­formes diffé­rentes et incom­pa­tibles, ou de migra­tion de données.

    Le tout c’est de ne pas abor­der l’angle tech­nique, qui lui effec­ti­ve­ment n’in­té­resse que le geek. Décen­tra­lisé ? c’est quoi qu’est-ce ?

    Diaspora ? Jabber ? StatusNet ? aucun inté­rêt

    Si rien n’avance, c’est que ce que nous propo­sons en alter­na­tive n’a que peu d’in­té­rêt. En propo­sant un remplaçant décen­tra­lisé à Face­book ou à MSN ce qu’on propose c’est de réali­ser main­te­nant et volon­tai­re­ment l’apo­ca­lypse dont on cherche à se proté­ger pour plus tard : perte des données, de son adresse, de ses rela­tions, et des inter­ac­tions avec le reste du monde.

    C’est même encore moins inté­res­sant puisque les services alter­na­tifs sont souvent moins abou­tis et n’au­ront d’in­té­rêt que si on réus­sit aussi à faire migrer toutes ses rela­tions (et qu’elles aussi y réus­sissent), ce qui n’ar­ri­vera pas.

    Même ceux qui n’ont pas encore de compte, donc pas de donnée ou d’adresse à perdre, n’ont pas vrai­ment le choix : Ils sont contraints par le choix des autres, sauf à rester seuls dans leur coin.

    Autant dire que les gens sensés préfèrent attendre que le pire arrive, quitte à ce que ça revienne au même. Ceux qui migrent le font par idéo­lo­gie ou par convic­tion, pas pour des raisons pratiques et prag­ma­tiques.

    Gérer son iden­tité

    Il nous faut pour­tant avan­cer et pour cela nous avons deux options : Créer le nouveau service ultime qui accueillera tous les utili­sa­teurs, en le faisant « bien » selon nos critères de liberté, de contrôle de son iden­ti­fiant, de vie privée, etc. ou s’oc­cu­per de la brique fonda­men­tale qui nous pose problème : la gestion d’iden­tité.

    J’ai besoin d’une brique pour gérer ce qui suit :

    • Annon­cer et prou­ver mon iden­tité
    • Présen­ter des infor­ma­tions diffé­rentes en fonc­tion de mon inter­lo­cu­teur
    • Accé­der aux infor­ma­tions que les autres me partagent
    • Délé­guer un service à un tiers tout en gardant le contrôle sur mon iden­ti­fiant
    • Avoir un iden­ti­fiant simple, mémo­ri­sable et mani­pu­lable par tous

    Si j’ai ça ensuite on pourra bran­cher des services unitaires dessus sans avoir à rempla­cer Face­book en entier.

    Du mieux

    Mais surtout, pour que ça fonc­tionne, il faut présen­ter mieux que l’exis­tant. Nous devons avoir un plus fonc­tion­nel immé­diat à propo­ser. Cet inté­rêt ne doit pas être simple­ment un inté­rêt tech­nique ou à long terme.

  • Non il n’y a pas pénu­rie d’in­for­ma­ti­ciens

    Pitié, arrê­tons avec ça. On nous a déjà fait le coup plusieurs fois. Remet­tons de l’ordre dans les légendes urbaines en utili­sant des indi­ca­teurs objec­tifs et pas du ressenti publiés par des gens qui y ont inté­rêt.

    L’in­for­ma­tique n’est pas en pénu­rie

    La tension du marché est carac­té­ri­sée par le ratio entre les offres et les demandes. Il y a 25 % moins d’offres que de demandes. C’est d’au­tant plus signi­fi­ca­tif que nous avons un domaine avec quelques spéci­fi­ci­tés comme un turn-over deux fois plus impor­tant que la moyenne et des annonces de recru­te­ment perma­nentes sur tous les sites de recru­te­ment pour alimen­ter des bases de profils.

    Nous avons 1 créa­tion de poste pour 4 recru­te­ments et pour 8 offres. Malgré cela nous avons encore un tiers plus de demandes que d’offres. Pour être encore plus clair : En 2010 il y a plus de nouveaux diplô­més en infor­ma­tiques que d’offres d’em­bauche pour ces primo-deman­deurs. Si ça c’est une pénu­rie, il faudra m’ex­pliquer.

    L’in­for­ma­tique a un taux de chômage consé­quent

    Le chômage des infor­ma­ti­ciens a même monté de 45 % sur 2009 si on prend en compte les primo-deman­deurs, après 7 mois succes­sif de hausse sur les derniers mois 2008.

    L’étude des années 2000 à 2010 montre un chômage moyen de 7,2 % avec des périodes de chômage struc­tu­rel de près de 80 % de la période. Il faut bien prendre en compte que sur les 20 % restants nous avons eu deux années d’eu­pho­rie qu’on a nommé après « la bulle Inter­net », qu’il est diffi­cile de consi­dé­rer comme repré­sen­ta­tives de la réalité ou de l’ave­nir.

    C’est d’au­tant plus signi­fi­ca­tif que 75 % des sala­riés du secteur sont des cadres, habi­tuel­le­ment moins touchés par le chômage. Le secteur n’est pas en pénu­rie, mais il n’est pas telle­ment mieux loti que le reste non plus. Il est par exemple factuel­le­ment moins porteur que l’agri­cul­ture (surtout si on compare au domaine « études et recherche »).

    L’em­bauche en infor­ma­tique n’est pas si diffi­cile

    Nous n’avons pas de pénu­rie, nous avons même un chômage struc­tu­rel. Alors, avons-nous au moins des diffi­cul­tés de recru­te­ment excep­tion­nelles ?

    L’APEC a deux statis­tiques inté­res­santes à ce niveau. Elle mesure un indi­ca­teur de diffi­culté d’em­bauche. Cet indi­ca­teur est dans notre secteur de 22 % pour les cadres et de 5 % pour les non-cadres. Il est à compa­rer à 20 % pour l’en­semble du secteur tertiaire. Nous n’avons donc pas de diffi­culté excep­tion­nelle pour les cadres, et une grande faci­lité pour les non-cadres. Pour réfé­rence le même indi­ca­teur est de 56 % dans l’in­dus­trie du bâti­ment et de 28 % pour l’in­dus­trie manu­fac­tu­rière.

    Le second indi­ca­teur mesure l’adé­qua­tion des embau­chés par rapport aux attentes. L’APEC nous indique que 92 % des recru­teurs estiment que l’écart entre le profil recher­ché et celui de la personne recru­tée est nul ou faible.

    Bref, recru­ter est diffi­cile, surtout pour un travail intel­lec­tuel. C’est vrai en infor­ma­tique comme ailleurs, mais pas plus qu’ailleurs, et pas à cause d’une soi-disante pénu­rie.

    Il n’y a pas de tensions sur les salaires en infor­ma­tique

    Cette absence de tension réelle se voit d’ailleurs sur les salaires. Étran­ge­ment si la statis­tique précé­dente nous dit que les profils recru­tés sont à 92 % conformes aux attentes, la même statis­tiques nous dit aussi que 85 % des salaires à l’em­bauche sont équi­va­lents ou infé­rieurs à ceux envi­sa­gés.

    Les salaires vont plutôt à la baisse par rapport aux attentes initiales sans que ce ne soit justi­fié par des profils moins compé­tents que prévu. Ce n’est pas réel­le­ment le reflet d’une diffi­culté à recru­ter.

    Pour­tant ces mêmes salaires sont déjà bas. L’ac­ti­vité « études, déve­lop­pe­ment et inté­gra­tion » a le 32ème salaire médian sur les 36 réfé­ren­cées, juste avant « études tech­niques et essais », « concep­tion », « recherche fonda­men­tale » et « autre ensei­gne­ment ». Ce n’est pas là non plus le reflet d’un marché en tension.

    Entre septembre 2010 et mars 2011 les salaires à l’em­bauche des cadres a augmenté de 2,9 % tous secteurs confon­dus, sans qu’on ne parle de pénu­rie. En infor­ma­tique et tele­com, il n’a été que de 0,4 % : 7 fois moins.

    Que cette ques­tion du salaire soit la source de la diffi­culté de recru­te­ment ou le signe de son absence relève de l’in­ter­pré­ta­tion, mais en tous cas ça ne colle pas avec un marché en tension et en pénu­rie.

    Mais alors, quel est le problème en infor­ma­tique ?

    Là nous entrons dans la partie d’opi­nion alors que le reste était basé sur des chiffres objec­tifs. Je réserve donc ça pour un billet séparé. Pour faire court ça tient tout de même en quelques points : SSII, acti­vité cyclique et évolu­tion de carrière.

  • Bon chas­seur et mauvais chas­seur : archi­tec­tures et données person­nelles

    Pour proté­ger les données des utili­sa­teurs il y a des bonnes archi­tec­tures et des mauvaises archi­tec­tures.

    C’est aussi simple que cela. Ne vous lais­sez pas dire que tous les systèmes sont faillibles, qu’il y a de bonnes raisons, ou que ce n’est pas impor­tant. C’est vrai, mais il reste que votre archi­tec­ture peut être bonne ou mauvaise. Ça aura un impact un jour ou l’autre, plus rapi­de­ment que vous ne l’es­pé­rez.

    Stocker en clair c’est mal

    Des gens meilleurs que vous s’y sont lais­sés prendre. Des socié­tés solides se sont faites avoir. Y compris des gens qui avaient de bonnes raisons tech­niques ou fonc­tion­nelles de faire ainsi.

    Rien ne change, si vous stockez les mots de passe en clair (ou de façon déchif­frable), un jour une faille logi­cielle ou système y donnera accès et vous aurez un gros problème avec vos utili­sa­teurs.

    Dans le meilleur des cas vous serez préve­nus rapi­de­ment et vous aurez juste une très mauvaise publi­cité comme Sony récem­ment, avec le risque de perdre la confiance de tous vos clients. Dans le pire… vous ne le remarquez que trop tard et vous pouvez mettre la clef sous la porte avec des problèmes juri­diques, finan­ciers et humains insol­vables.

    Ne pas utili­ser SSL / TLS pour les commu­ni­ca­tions réseau c’est mal

    Des gens meilleurs que vous s’y sont lais­sés prendre. Des socié­tés plus solides se sont faites avoir. Ai-je besoin de tout répé­ter ?

    Si vous ne chif­frez pas toutes les commu­ni­ca­tions réseau avec vos clients dès que vous trans­fé­rez des données sensibles, vous prenez un risque impor­tant pour la sécu­rité des dites données. Chif­frer unique­ment la phase d’au­then­ti­fi­ca­tion ne suffit pas, quoi qu’on vous dise.

    Vos utili­sa­teurs ont besoin d’une connexion sécu­ri­sée. Tout le reste n’est que bidouillage et mauvaise archi­tec­ture. Tôt ou tard il y aura un abus d’un état, d’un FAI, d’une entre­prise, d’une école, qui aura un peu de publi­cité et qui vous posera un problème impor­tant.

    Chif­frer avec la clef de déchif­frage sur le serveur c’est mal

    Non, je ne vais pas me répé­ter encore une fois, si ce n’est pour dire que vous n’êtes pas un cas spécial.

    Chif­frer et déchif­frer sur le serveur en lais­sant la clef sur place, c’est comme avoir une porte blin­dée avec serrure trois points et lais­ser la clef sous le pot de fleur à côté. Pour faire court, si c’est le serveur qui chiffre, déchiffre, et gère la clef, c’est comme si vos données étaient en clair, ou presque.

    Drop­box avait fait de la publi­cité autour de la sécu­rité de leur service. Ils avaient une unique clef de chif­frage, sur leur serveur. Les utili­sa­teurs ont râlé, fait de la mauvaise publi­cité, et même porté plainte. D’au­cuns ont dit que ce n’était pas impor­tant.

    Voilà hier qu’un problème tiers a donné accès pendant quatre heures à toutes les données de tout le monde, sans mot de passe. Ça ne serait pas arrivé si chaque client gérait sa propre clef, sans la parta­ger avec Drop­box.

    Les râleurs n’avaient pas de boule de cris­tal, ce qui est arrivé était évident. On savait que ça arri­ve­rait, et on peut dire que les consé­quences ont été les extra­or­di­nai­re­ment faibles par rapport aux risques. La prochaine fois ce sera bien plus gênant.

    Quelle que soit la raison, une mauvaise archi­tec­ture reste mauvaise

    Il se peut qu’on soit obligé d’uti­li­ser une mauvaise archi­tec­ture. Il se peut que cette mauvaise archi­tec­ture soit un compro­mis accep­table, ou même souhai­table en fonc­tion de besoin spéci­fiques.

    C’est rare, tout le monde a tendance à se penser dans le cas excep­tion­nel alors que ce n’est pas le cas, mais ça peut arri­ver. Mais, même dans ce cas, il ne faut pas perdre de vue que ça reste une mauvaise archi­tec­ture, et qu’on en subira les consé­quences.

    Il y a des bonnes et des mauvaises archi­tec­tures, c’est ainsi. Faites ce que vous pensez le mieux, il se peut que vous ayez de bonnes raisons de choi­sir la mauvaise archi­tec­ture (même s’il y a toutes les chances que vous fassiez erreur). Mais quelles que soient ces raisons, elles ne trans­for­me­ront pas votre mauvaise archi­tec­ture en « bonne » archi­tec­ture. Vous venez de choi­sir une mauvaise archi­tec­ture pour de bonnes raisons, voilà tout. Et vous allez le payer.

  • Iden­ti­fiant utili­sa­teur et message d’er­reur

    L’uti­li­sa­teur ou le mot de passe four­nis est inva­lide

    Oui mais euh… lequel ?

    J’ai un compte sur plus d’une dizaine de services courants, peut être une ou plusieurs centaines si je compte les boutiques et forums en ligne sur lesquelles je vais peu.

    Expé­rience utili­sa­teur à jeter

    Malheu­reu­se­ment, comme tout le monde, je n’ai pas pu ou voulu avoir le même iden­ti­fiant utili­sa­teur partout. Parfois je me trompe, parfois je ne suis même pas capable de savoir lequel est le bon. Bien entendu j’ai aussi pas mal de mots de passe.

    Pas de doute, ce message d’er­reur rend plus diffi­cile de rentrer sur le compte. En tout cas c’est vrai pour l’uti­li­sa­teur légi­time. Ce qui aurait pu lui permettre de s’iden­ti­fier en quelques minutes lui pren­dra un bon quart d’heure le temps de tester toute une combi­nai­son d’iden­ti­fiants utili­sa­teur et la croi­ser avec autant de mots de passe.

    L’iden­ti­fiant utili­sa­teur n’est pas une sécu­rité

    La raison d’être de ce message est souvent un déve­lop­peur qui a souhaité amélio­rer la sécu­rité. Le fonde­ment est logique, si l’iden­ti­fiant utili­sa­teur est une incon­nue, cela fait une entrée de plus à forcer ou devi­ner.

    Mais en même temps, si en connais­sant l’iden­ti­fiant utili­sa­teur il est possible de forcer le compte rela­ti­ve­ment simple­ment, vous avez un vrai problème, et ce problème ne vient pas de l’iden­ti­fiant utili­sa­teur. Vous venez d’ajou­ter de cacher le cade­nas parce qu’il est trop simple à forcer quand on le trouve. Est-ce réel­le­ment la bonne approche ?

    Trou­ver un iden­ti­fiant utili­sa­teur est simple

    S’il s’agit de tester des iden­ti­fiants communs à l’aide d’un diction­naire et que nous parlons d’un service grand public, ne nous voilons par la face : Nous savons que « bob », « bob75 » et « great­bob » existent. Il n’est pas besoin de les tester. C’est même à cause de cette pré-exis­tence extrê­me­ment probable que vos utili­sa­teurs ont des iden­ti­fiants diffé­rents partout.

    Si à l’in­verse vous visez un utili­sa­teur parti­cu­lier, si vrai­ment l’in­gé­nie­rie sociale n’est d’au­cune aide à l’at­taquant (ce qui serait éton­nant), il lui restera à tester quelques variantes les plus probables dans votre robot. Ce qui est extrê­me­ment pénible à faire pour un humain ne chan­gera pas l’ordre de gran­deur du problème pour le robot et ne rendra pas beau­coup plus ou beau­coup moins fiable votre système.

    Pire, si vrai­ment il s’agit de décou­vrir l’exis­tence d’un iden­ti­fiant, et si vous tentiez une créa­tion de compte avec l’iden­ti­fiant en ques­tion ? On ne vous dit pas si l’iden­ti­fiant est dispo­nible à ce moment là ? Était-ce bien la peine de complexi­fier l’ex­pé­rience utili­sa­teur d’un côté si l’in­for­ma­tion est dispo­nible faci­le­ment ailleurs ?

    Votre sécu­rité est ailleurs

    Vous voulez augmen­ter la sécu­rité ? impo­sez un méca­nisme de double authen­ti­fi­ca­tion, un nombre d’es­sai maxi­mum, une tempo­ri­sa­tion d’une dizaine de secondes, des mots de passe forts, ou même deux carac­tères de plus dans votre mot de passe. Voilà, votre sécu­rité est aussi bien voire mieux assu­rée qu’en cher­chant à donner un message d’er­reur peu expli­cite à l’uti­li­sa­teur.

    Si réel­le­ment l’iden­ti­fiant utili­sa­teur était un compo­sant de sécu­rité, autant le mettre en champ « mot de passe » au lieu d’avoir un champ texte en clair. Mieux, on impo­se­rait une longueur mini­male et on inter­di­rait les iden­ti­fiants courants. En allant au bout de la démarche on pour­rait même faire un seul champ « utili­sa­teur et mot de passe » puisque l’iden­ti­fiant utili­sa­teur ne sert pas à grand chose d’autre.

    Je ne sais pas si vous avez vu mais on retombe sur nos pas : pour amélio­rer la sécu­rité, ajou­tez des carac­tères au mot de passe, ne prenez pas l’iden­ti­fiant utili­sa­teur pour un mot de passe.

    L’iden­ti­fiant utili­sa­teur comme donnée de valeur

    Vient un dernier problème qu’on m’a soumis : Parfois l’iden­ti­fiant utili­sa­teur peut lui même être une donnée de valeur.

    Je trouve dans cette caté­go­rie des extra­net dont l’iden­ti­fiant utili­sa­teur est prédic­tible mais où l’ap­par­te­nance de l’uti­li­sa­teur au système donne une infor­ma­tion impor­tante. Ce peut par exemple être l’ex­tra­net d’un avocat pour savoir si une personne précise est cliente.

    Ça ne concerne pas les services publics, ça ne concerne pas les services où les iden­ti­fiants sont non prédic­tibles, ça ne concerne par les récoltes anonymes (où on ne vise pas un utili­sa­teur précis) et ça ne concerne que les cas où l’iden­ti­fiant utili­sa­teur a une valeur en soi. C’est rare, plus proba­ble­ment la solu­tion serait de rendre l’iden­ti­fiant anonyme ou non prédic­tible, mais ce sont des cas légi­times.

    Par contre, pour votre boutique en ligne, pour votre forum, non, il n’y a aucune raison de gêner l’uti­li­sa­teur à ce point, vrai­ment.

  • Perplexité, complexité, vélo­cité … une autre vue

    J’ai lu « Perplexité, complexité, vélo­cité » sur le blog d’OCTO. L’ar­ticle est bien tourné et on sort complè­te­ment convaincu. Mon problème c’est que quelques heures après j’ai commencé à avoir des doutes et plus les jours avancent plus mes doutes se trans­forment en avis contraire. Je vous encou­rage à lire d’abord le billet d’OCTO, le mien n’aura de sens qu’en réponse.

    À quoi sert la vélo­cité ?

    À quoi sert la vélo­cité ?

    1.     Esti­mer ce qui sera réalisé ou non dans le sprint

    2.     Mesu­rer la produc­ti­vité de l’équipe

    3.     Mesu­rer le réalisé pour le projet, le produit

    Ma diver­gence avec l’ar­ticle source vient d’un constat simple : Nous n’uti­li­sons pas cet indi­ca­teur dans le même objec­tif. Lui l’uti­lise pour mesu­rer la produc­ti­vité, moi pour amélio­rer les esti­ma­tions.

    Amélio­rer les esti­ma­tions

    Amélio­rer les esti­ma­tions c’est faire en sorte de mieux évaluer ce qui sera livré dans chaque sprint et aider à la prio­ri­sa­tion. Bref, gérer le projet.

    Pour amélio­rer nos esti­ma­tions on tente de se baser sur les tâches simi­laires précé­dentes et on en réuti­lise l’es­ti­ma­tion sans tenir compte de la produc­ti­vité de l’équipe. On utilise pour cela une unité virtuelle qui nous détache des jours/hommes : le point. Réali­ser une esti­ma­tion ainsi est de plus en plus simple, rapide et fiable.

    Pour prendre en compte les évolu­tions de produc­ti­vité (équipe plus effi­cace ou dette tech­nique gran­dis­sante) c’est le nombre de points réali­sable dans un sprint qu’on fait varier. Afin de ne pas sortir le dé pour évaluer ce nombre de points, on se base sur ce qui a été réalisé dans les quelques sprints passés et on tente de rester sur une courbe la plus stable possible.

    Nos réfé­rences d’es­ti­ma­tion sont stables, nos esti­ma­tions se fiabi­lisent avec le temps. Le nombre magique de points qu’on peut mettre dans un sprint, c’est pour moi ce qu’est la vélo­cité de l’équipe.

    En prenant en compte la tech­nique

    Si on calcule en points et pas en heures ou en jours, ce n’est pas parce qu’on compte en complexité fonc­tionne, c’est pour s’au­to­ri­ser à faire varier la somme totale plutôt que chaque esti­ma­tion.

    Il ne faut pas perdre de vue que notre objec­tif reste bien d’éva­luer une charge de déve­lop­pe­ment. Il faut donc tenir compte dans nos esti­ma­tions de tout ce qui est néces­saire à évaluer le temps de déve­lop­pe­ment et livrer la fonc­tion­na­lité : Ça va des besoins fonc­tion­nels à la complexité tech­nique en passant par les contraintes orga­ni­sa­tion­nelles spéci­fiques.

    Si je ne prends en compte que la complexité fonc­tion­nelle, l’es­ti­ma­tion n’aura plus aucun lien avec le temps de déve­lop­pe­ment. Pour savoir ce qui tient ou pas dans le sprint, on en vien­dra à faire une esti­ma­tion globale, au jugé, sans réfé­rences simi­laires : tout l’in­verse de l’objec­tif.

    Outil privé versus indi­ca­teur public

    À mon humble avis l’er­reur de l’ar­ticle n’est pas seule­ment de faire de la vélo­cité une mesure de produc­ti­vité, c’est en plus de l’avoir commu­niquée à l’ex­té­rieur de l’équipe.

    Du coup, forcé­ment, la vélo­cité devient un enjeu poli­tique. L’équipe, son mana­ger, son coach commencent à avoir inté­rêt à amélio­rer l’in­di­ca­teur au lieu de se concen­trer sur ce qui devrait être leur seul objec­tif : appor­ter de la valeur au produit.

    Que la vélo­cité augmente, dimi­nue, c’est quelque chose propre à l’équipe. S’il faut un indi­ca­teur de produc­ti­vité et de pertur­ba­tion, il faut publier la seule chose impor­tante : la progres­sion de la valeur du produit (si ça ressemble au para­graphe précé­dent, ce n’est pas une coïn­ci­dence).

    Cette vélo­cité doit être prise pour ce qu’elle est : un outil d’es­ti­ma­tion, de plani­fi­ca­tion et de prio­ri­sa­tion. Comme tous les outils, il a voca­tion à être utilisé en interne, par l’équipe, et nulle part ailleurs.

    Et la complexité fonc­tion­nelle ?

    Mon second problème est là : Selon moi la complexité fonc­tion­nelle n’in­dique rien de valable. Ce n’est pas une mesure de ce que coûte la fonc­tion­na­lité, ce n’est pas une mesure de ce qu’ap­porte la fonc­tion­na­lité, et inci­dem­ment ce n’est pas une mesure de l’im­pli­ca­tion ou de la produc­ti­vité de l’équipe.

    Tout au plus la complexité fonc­tion­nelle permet de faire une première esti­ma­tion des histoires utili­sa­teurs qui ne sont pas prévues pour tout de suite ou dont on ne connaît pas la complexité tech­nique.

  • Réso­lu­tions d’écran – mai 2011

    Petite statis­tiques abso­lu­ment pas repré­sen­ta­tive mais inté­res­sante quand même : les réso­lu­tions d’écran des gens qui sont passés sur ce site du 1 au 12 mai 2011.

    Petite inter­pré­ta­tion perso :

    • J’ai moins de 10% de visites de mobile (réso­lu­tion infé­rieure à 1024px)
    • Je dois avoir envi­ron 3% de netbook et tablettes (réso­lu­tion de 1024px mais pas plus)
    • Les desk­top supportent tous ou presque au moins 1280px (87% de support, mobiles inclus)
    • Les mobiles sont tous diffé­rents et il est diffi­cile d’ac­ter d’une réso­lu­tion mini­male stan­dard sauf à la prendre vrai­ment très petite
    Avec comme consé­quence sur le design, si on doit faire plusieurs versions:
    • Une version mini­male à 240 ou 280px, quitte à ce qu’elle soit très dégra­dée
    • Une version à 800 (android récent en paysage), qui servira aussi pour les iphone avec une meilleure réso­lu­tion, les tablettes et les netbooks
    • Une version desk­top à 1280, qui sera la version « stan­dard »
    • Une à 1400 ou 1600 pour récu­pé­rer les écrans larges
    • Et si je suis bien luné une version à 1900 parce que ça concerne quand même encore un quart des visites
    Atten­tion, ces chiffres ne prétendent pas être repré­sen­ta­tifs de quoi que ce soit, et ne repré­sentent que des réso­lu­tions d’écran, pas des tailles de fenêtre, ce qui est nette­ment diffé­rent.

  • JSON c’est hype

    J’en ai marre de voir du JSON partout. J’ai même vu des gens propo­ser de rempla­cer du XML par du JSON juste parce que c’est plus moderne, plus léger et plus compa­tible. « JSON is the new XML » est un effet de mode, un mauvais effet de mode. On va se retrou­ver comme avant avec des gens qui vont se réveiller dans quelques mois/années avec des formats de données pas du tout adap­tés à leur usage.

    Coupons un peu dans le tas :

    JSON n’est pas vrai­ment plus simple à lire par un humain

    Pour un petit fichier en volume comme en hiérar­chie, le JSON a un léger avan­tage sur le XML mais ce n’est pas fran­che­ment signi­fi­ca­tif.

    Pour un gros fichier ou avec beau­coup de hiérar­chie, le JSON devient complè­te­ment illi­sible à suivre au niveau des imbri­ca­tions.

    JSON n’est pas plus simple à écrire par un humain

    JSON est un peu moins verbeux mais plus propice aux erreurs : facile d’ou­blier une virgule en fin de ligne, ou d’en mettre une par erreur à la dernière ligne. Sur les gros fichiers les niveaux d’im­bri­ca­tion seront eux aussi un écueil à l’écri­ture.

    En compa­rai­son la verbo­sité d’XML rend diffi­cile les erreurs et le dispo­ni­bi­lité de fichiers gram­maire permettent de faire de l’aide à la saisie voire de vali­der en tems réel le contenu.

    La diffé­rence de poids n’est pas signi­fi­ca­tive

    JSON est plus léger que le XML d’en­vi­ron un tiers (pour des fichiers forte­ment struc­tu­rés, beau­coup moins pour les autres). À moins de 1,5 Ko une fois compressé en gzip (donc 6 Ko non compressé) ça tient dans un paquet TCP/IP et 500 octets de moins ne changent stric­te­ment rien. Sur disque on compte de toutes façons au moins par paquets de 4K.

    Pour faire une diffé­rence signi­fi­ca­tive de 10 Ko sur le réseau il faut une donnée de 160 Ko avant compres­sion. Ça concerne d’au­tant moins de monde qu’à ce volume le JSON n’est plus du tout lisible.

    JSON n’est pas plus natif que XML

    XML est natif sur tous les outils, langages et navi­ga­teurs depuis des années là où JSON n’a d’API native que sur les navi­ga­teurs récents, certains langages et quelques outils.

    JSON est en fait natif en javas­cript via eval(), mais ça n’est pas plus perfor­mant. Pour une même donnée, lire du XML via DOM est 30% plus rapide que lire du JSON avec eval(). Pour avoir sécu­rité et fiabi­lité en lecture, ou pour faire de l’écri­ture JSON, il faudra une biblo­thèque pas native du tout sur IE7 ou Safari pour iPhone 3.2. Elle fera au moins 5 Ko et ne sera donc renta­bi­li­sée par rapport au XML natif que si on trans­fert au moins 15 Ko de JSON.

    JSON n’est pas vrai­ment exten­sible ou évolu­tif

    JSON permet souvent d’ajou­ter de nouvelles clefs sans modi­fier casser la compa­ti­bi­lité. Si on souhaite ajou­ter une date de mise à jour à une liste de chaînes de carac­tères, il faudra toute­fois modi­fier le format, mettre à jour tous les outils concer­nés. Si on souhaite mixer des formats diffé­rents là ça devient vite un casse-tête et des solu­tions bidouille.

    En XML on a la possi­bi­lité d’in­sé­rer des méta-données dans des attri­buts, ainsi que de mixer diffé­rents concepts ou formats à l’aide d’es­paces de noms. Ce sont des fonc­tion­na­li­tés qui ont leurs limites, mais qui ont prouvé appor­ter un peu de souplesse et d’évo­lu­ti­vité aux formats créés.

    Compa­tible avec l’exis­tant

    Outre le concept de « natif », beau­coup d’ou­tils, d’ap­pli­ca­tions, de progi­ciels ou de chaînes de trai­te­ment sont adap­tés à l’ex­ploi­ta­tion ou à l’ex­por­ta­tion de données XML. Côté JSON les plus récents savent faire de l’ex­port, tout le reste est à trai­ter en spéci­fique.

    Sur l’exis­tant XML j’ai des concepts de signa­ture, des mapping XML-Objet en Java, des outils qui font du filtre ou du routage, de la vali­da­tion, des compo­si­tions entre données XML.. tout ça n’existe simple­ment pas en JSON. Quand (si) j’en aurai besoin, il faudra réin­ven­ter la roue.

    Hype, mode et trucs de jeunes déve­lop­peurs inno­vants

    JSON était simple au départ parce qu’on utili­sait eval(), que ça renvoyait immé­dia­te­ment sur un objet javas­cript sans deman­der au déve­lop­peur client de faire des mani­pu­la­tions complexes ou de char­ger une biblio­thèque de plus. Ça a permis d’ou­vrir quelques API à des gens qui auraient eu du mal autre­ment. C’est indé­nia­ble­ment posi­tif sur ce point là.

    Ensuite s’est rendu compte que pour la fiabi­lité et la sécu­rité il fallait du code en plus. Faire des petites fonc­tions qui lisent du XML simple pour créer des objets javas­cript natifs aurait été plus simple, plus perfor­mant et moins lourd mais c’était trop tard : c’était « hype ». Du coup on a utilisé des biblio­thèques d’ana­lyse de 10 Ko de pur javas­cript pour lire des JSON de moins de 1 Ko et annon­cer que ces derniers étaient moins lourds que le XML corres­pon­dant. Allez comprendre.

    Depuis on a des fonc­tions natives dans les navi­ga­teurs récents et un peu plus de support dans les outils récents (c’est la mode, il a bien fallu faire avec et suppor­ter le nouvel usage) donc ça a du sens pour quelques usages (échange de petites données struc­tu­rées avec un navi­ga­teur récent) mais la mode prend encore trop le pas sur des grilles de compa­rai­son argu­men­tées et factuelles et même dans les usages les plus adap­tés, le béné­fice sur le XML est rare­ment très signi­fi­ca­tif.

  • Ce que j’at­tends comme chan­ge­ment dans les offres mobiles

    Ça buzz en ce moment sur des « révo­lu­tions » dans les offres mobiles. On parle d’illi­mité acces­sible, dans les 40 € par mois. Il faut dire que quand on regarde chez certains de nos voisins on a l’im­pres­sion de payer la minute de commu­ni­ca­tion à prix d’or. Mais en même temps je ne connais personne qui télé­phone en illi­mité. Un gros forfait pas cher, voilà simple­ment ce qui arrive.

    J’at­tends de voir l’offre pour juger mais entre temps voilà ce qui selon moi consti­tue­rait une réelle révo­lu­tion dans le milieu :

    J’achète un forfait, pas un mobile

    Ne plus inté­grer le prix d’un nouvel appa­reil dans les forfaits télé­pho­niques. Cela n’em­pêche pas l’opé­ra­teur de propo­ser d’ai­der au finan­ce­ment d’un nouveau mobile en en lissant le prix sur une année, mais en tant qu’op­tion, clai­re­ment distincte du forfait.

    Je m’en­gage sur un à trois mois seule­ment

    Le second effet Kiss-Cool de la sépa­ra­tion du forfait et du mobile c’est que du coup il n’y a plus de justi­fi­ca­tion à deman­der un enga­ge­ment de plus de 3 mois. Fini le boulet au pied pendant un à deux ans, main­te­nant je veux pouvoir partir quand je veux.

    J’uti­lise mon accès comme je le veux

    Je paye un forfait avec de la voix, des données. Je veux pouvoir utili­ser cette voix et ces données comme je le souhaite : sur mon télé­phone, sur une tablette, ou même via un micro-ordi­na­teur. Je ne veux pas de bridage de débit, de bridage de port. Je ne veux pas une factu­ra­tion hors forfait pour un usage en mode modem.

    À dire vrai je n’ai pas toujours été de ce dernier avis mais ce mode de factu­ra­tion est jugé illé­gi­time et anor­mal par tous les clients visés. Il doit être changé en consé­quence.

    J’ai un télé­phone non bidouillé

    Enfin, pour ceux qui utilisent des smart­phones, je veux un télé­phone non bidouillé, sans surcouche opéra­teur, sans person­na­li­sa­tion, sans logi­ciel en version démo. Si l’opé­ra­teur veut four­nir des appli­ca­tions, des thèmes, des fonds d’écrans, qu’il le fasse, mais par les canaux prévus pour, pas via des surcharges non désins­tal­lables qui en plus empêchent d’ins­tal­ler les mises à jour du construc­teur.

    Voilà ma révo­lu­tion mobile, le prix dans tout ça c’est juste une variable, qui finira toute seule par descendre quand les utili­sa­teurs auront plus de liberté et plus de clarté sur ce qu’ils achètent.

  • La factu­ra­tion est une science complexe

    Choi­sir comment factu­rer un service est une chose complexe et vous avez inté­rêt à y réflé­chir deux fois. Trois ou quatre serait même une bonne idée.

    Au restau­rant on paye le plat

    Imagi­nons que vous lanciez un restau­rant. Vous pouvez faire comme tout le monde et factu­rer les mets à la carte. Pour­tant ce qui vous coûte cher c’est aussi le restau­rant lui-même, le service et le couvert. En factu­rant au plat vous répar­tis­sez tous ces coûts annexes sur chaque plat. C’est ce qui fait qu’un simple plat semble toujours couter cher quand il est pris indé­pen­dam­ment.

    Pour peu que votre cuisine soit une réus­site c’est la place qui devien­dra votre ressource la plus limi­tée. Le couple de jeunes qui prend juste une salade et fait des mamours pendant long­temps devien­dra votre bête noire. S’ils partagent une salade ou un dessert, c’est la misère : Vous écono­mi­sez le coût de quelques feuilles de salade mais en échange vous n’en factu­rez qu’une et ils bloque­ront la table en vous empê­chant de faire un second ou un troi­sième service avec des gens qui pren­dront deux bons gros plats.

    Il faut dire que c’est un peu de votre faute : En répar­tis­sant les coûts ainsi ceux qui prennent entrée – plat – dessert payent une partie des coûts annexes de ceux qui ne prennent qu’une salade. Vous deve­nez attrac­tif pour ce qui est votre pire clien­tèle et peu inté­res­sant pour ceux qui vous rapportent le plus. Pas très malin.

    Sur Inter­net on paye l’ac­cès au réseau interne

    Cette problé­ma­tique se retrouve bien évidem­ment dans notre petit monde de Inter­net :

    Votre four­nis­seur d’ac­cès Inter­net paye deux choses : Un coût à peu près fixe pour vous connec­ter à son réseau, et un coût dépen­dant des usages (ou de leur augmen­ta­tion) pour connec­ter son propre réseau à tous les sites que vous visi­tez.

    Nos FAI français ont choi­sit le modèle inverse des restau­ra­teurs français : Ils proposent des forfaits, faisant donc payer prin­ci­pa­le­ment l’ac­cès à leur réseau interne. Les autres coûts sont réin­té­grés sur ce forfait en faisant une moyenne des usages prévus.

    Comme un gros utili­sa­teur conti­nue à coûter plus cher qu’un autre, on entre dans la quatrième dimen­sion : Votre FAI a donc inté­rêt à ce que vous utili­siez le moins possible ce pour quoi vous faites appel à lui : accé­der à Inter­net.

    Le modèle de factu­ra­tion va à l’en­contre des inté­rêts du four­nis­seur de service. Il n’est perti­nent que pour des raisons marke­ting.

    La stra­té­gie du pour­ris­se­ment

    Le résul­tat premier c’est que forcé­ment les FAI sont plus inté­res­sés à offrir des services addi­tion­nels (TV, VOD, lecteurs bluray et autres bonus liés aux « box ») qu’à corri­ger vos problèmes d’ac­cès ou vous offrir de bons accès Inter­net. Regar­dez la commu­ni­ca­tion : On vous parle plus de télé­phone, télé­vi­sion, et box que d’ac­cès Inter­net. Vous savez désor­mais pourquoi. Si vous cher­chez une expli­ca­tion à une majo­rité de vos problèmes ou de leur non réso­lu­tion, vous l’avez aussi main­te­nant. Ce n’est pas qu’ils ne s’en (pré)occupent pas, c’est juste que leurs prio­ri­tés sont ailleurs.

    Le résul­tat second c’est que nos FAI qui doivent quand même faire face aux usages gran­dis­sants. L’en­nemi appa­raît vite : Les éditeurs de site web ont un modèle écono­mique opposé à celui des FAI. Ces méchants éditeurs ont inté­rêt et encou­rage à utili­ser de plus en plus le réseau (et ça ce n’est pas bon pour nos FAI qui facturent au forfait). Il faut les faire payer, soit par une taxe (ça parle à quelqu’un la « taxe Google » ?) soit par la force dans les quelques projets que les deux ont en commun (héber­ge­ment des serveurs de cache, liens de peering, etc.)

    Au lieu de parte­na­riats gagnants-gagnants, le modèle de nos FAI impose de gérer une rela­tion d’en­ne­mis avec les éditeurs et de faire de l’uti­li­sa­teur la cinquième roue du carrosse.  Main­te­nant vous pouvez relire le billet de Korben, ou vous souve­nir des fameuses « QoS » mises en place sur certains ports par vos FAI.  Si bien entendu la situa­tion est plus complexe et plus complète que ce que vous avez lu ici ou chez lui, cela vous donne déjà une bonne base d’ana­lyse.

    Factu­rer au volume

    Note: Je vois que les commen­taires se fixent sur cette section. Je voulais poser un problème, je me suis aven­turé un peu sur une solu­tion. Peut-être n’au­rais-je pas du le faire avant d’avoir une réflexion plus complète, peut être aurais-je du faire un billet dédié séparé. Je ne sais pas. Ne vous foca­li­sez pas sur la ques­tion de la factu­ra­tion au volume. Le coeur de mon propos est plus d’ex­pliquer le problème, pas d’af­fir­mer avoir « la » solu­tion. Gardez-le juste à l’es­prit dans vos réac­tions.

    Côté Inter­net on dépeint une factu­ra­tion au volume consommé comme la pire des évolu­tions possibles. Pour­tant cela résou­drait pas mal de problé­ma­tiques :

    • Les éditeurs de sites web seraient désor­mais des parte­naires, puisqu’ils encou­ragent l’usage du service
    • Les éditeurs auraient une pres­sion des utili­sa­teurs pour ne pas encom­brer inuti­le­ment le réseau, puisque cela leur coute­rait plus cher
    • On peut propo­ser un accès mini­mal peu cher car les petits utili­sa­teurs ne payent pas pour les gros
    • Les offres de contenu légales devien­draient de fait (un peu) plus atti­rantes vu que le télé­char­ge­ment Inter­net ne serait plus gratuit
    • On favo­ri­se­rait enfin l’émer­gence de plate­formes décen­tra­li­sées (les services locaux au FAI ou au pays coûtent peu par rapport aux sites distants)

    Bien entendu si certains finissent par payer moins cher, d’autres paie­ront plus cher mais n’est-ce pas légi­time au final ?

    Les craintes viennent d’an­ciens modèles écono­miques qui fonc­tion­naient au quota, avec éven­tuel­le­ment une factu­ra­tion du hors forfait à des tarifs dispro­por­tion­nés, mais ce n’est pas du tout un passage obligé. Ce que change la factu­ra­tion au volume c’est la façon de factu­rer, pas forcé­ment le montant de la facture moyenne.

    De toutes façons on y vien­dra. Malgré la mauvaise volonté de nos FAI les usages augmentent régu­liè­re­ment. Il y a un moment où le diffé­ren­tiel entre les petits usagers et les gros ne sera plus tenable. Plus tôt on y passera plus tôt on aura enfin un réseau que tout le monde aura inté­rêt à gérer et à amélio­rer au lieu de traî­ner les pieds.

    Réflé­chir à sa factu­ra­tion

    Ces ques­tions ne sont pas retreintes aux restau­rants et aux four­nis­seurs d’ac­cès Inter­net. Si l’ac­tua­lité est un bon prétexte pour abor­der le sujet, c’est à propos de plusieurs projets en élabo­ra­tion que j’ai eu cette discus­sion récem­ment :

    Faites atten­tion à ce que vous factu­rez. Votre factu­ra­tion doit inci­ter vos clients et vos parte­naires à augmen­ter leur usage de vos services et établir une évolu­tion gagnant-gagnant.

    Deux signes néga­tifs qui ne trompent pas :

    • Si vous aviez un bouton magique qui amélio­re­rait votre service, vous n’au­riez pas inté­rêt à appuyer dessus
    • Vous atti­rez prin­ci­pa­le­ment les clients qui vous inté­ressent le moins, et inver­se­ment.

    Les restau­rants n’ont qu’un seul de ces signes néga­tifs. Les FAI français cumulent malheu­reu­se­ment les deux et ça finira forcé­ment par écla­ter.

  • Sud Web : La confé­rence des métiers du web dans le sud

    Nous avons monté Paris Web il y a main­te­nant quelques années pour parler du web, de ses métiers, de retours d’ex­pé­riences de profes­sion­nels sur la qualité, l’ac­ces­si­bi­lité et la publi­ca­tion sur le réseau. Depuis lors on nous a demandé « et pour les gens du sud alors ? ».

    Cette année quelques uns ont pris leur courage à deux mains pour créer Sud Web, un événe­ment avec une des meilleurs tagline qu’on puisse imagi­ner : savoir-faire et faire-savoir. Avec le soutien de parte­naires locaux comme la recom­man­da­tion de noms pres­ti­gieux comme le W3C, le programme qui s’an­nonce peut mettre au défi une grande majo­rité des événe­ments web français du domaine.

    Si c’est incon­tour­nable pour les passion­nés et les amou­reux du web, c’est aussi une étape de forma­tion conti­nue et d’ex­plo­ra­tion de l’état de l’art avec un recul que vous ne pour­rez pas compen­ser par quelques lectures en ligne ou par une session de forma­tion entre quatre murs.

    Tout ça c’est à Nîmes, fin mai, le 27 exac­te­ment. Pour ceux qui veulent renta­bi­li­ser leur dépla­ce­ment c’est précédé le 26 par une jour­née centrée autour de l’ex­pé­rience utili­sa­teur : Web UX. Alors ce n’est pas à Paris, mais entre le soleil et l’hé­ber­ge­ment moins coûteux qu’à la capi­tale, on s’y retrouve rapi­de­ment ; et puis ça vaut large­ment le billet de train, tout simple­ment.

    Il reste des places, prenez votre courage à deux mains et jouez des pieds pour bouger votre employeur afin de vous inscrire.