Catégories
Architectures ouvertes

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.

Catégories
Métiers du web Vie professionnelle

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.

Catégories
Architectures ouvertes

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.

Catégories
Politique et société

Depuis quand est-ce normal ? – service public

Depuis quand est-ce accep­table d’at­tendre 4 à 7 heures aux urgences d’un hôpi­tal ?

Si la ques­tion n’est pas de moi elle résonne très bien dans mon esprit. Ça aurait certai­ne­ment pu arri­ver il y a 30 ans, mais je ne crois sérieu­se­ment pas que cela aurait été consi­déré comme « normal ».

Le tour de force

Quand j’ai posé la ques­tion autour de moi on m’a parlé caté­go­ri­sa­tion des urgences, de prio­ri­sa­tion, de la surcharge des services avec des urgences non vitales, de ce que devrait être le travail d’un méde­cin urgen­tiste, de la possi­bi­lité de donner des anti-douleurs pour aller voir le lende­main son méde­cin géné­ra­liste quand ce n’est pas vital, etc.

Au final toutes ses réponses reviennent au même dans mon esprit : Nous caté­go­ri­sons et nous justi­fions la baisse de qualité du service globale par la néces­sité de trai­ter correc­te­ment la caté­go­rie la plus vitale.

Cela revient simple­ment à dire que nous manquons de moyen pour trai­ter tout le monde correc­te­ment. Le tour de force commu­ni­ca­tion­nel est d’être arrivé à ce que les consé­quences de ce manque de moyen soit consi­déré comme « normal ».

Non ce n’est pas normal

Parce que non ce n’est pas normal. Que ça puisse arri­ver excep­tion­nel­le­ment à cause d’une affluence impré­vi­sible je ne le nie pas. Que ce soit fréquent ou normal ça je ne peux pas être d’ac­cord.

S’il y a du mauvais routage il doit être détecté et renvoyé ailleurs lors de l’ac­cueil. Bien évidem­ment il n’est pas accep­table qu’un service d’ur­gence mette plusieurs heures avant de quali­fier une arri­vée.  Visi­ble­ment ça arrive tout de même.

Expé­rience perso: j’ai attendu 4h une radio qui détecta un pneu­mo­tho­rax. Je suis passé de l’étiquette verte au bloc opé en 10min — Cyprien

Il n’est pas non plus normal d’at­tendre plusieurs heures après ce premier tri. Si le cas est jugé « retour­nez chez vous » ou « prenez rendez vous chez votre méde­cin pour la semaine prochaine » alors la ques­tion ne se pose pas. Si par contre le cas doit être traité avant de renvoyer le patient chez lui, alors attendre 4 ou 7 heures n’est proba­ble­ment pas accep­table et ne doit donc pas être « normal » (dans le sens « non excep­tion­nel).

De la dégra­da­tion du service public

Vrai­sem­bla­ble­ment le délai d’at­tente aux urgence s’est allongé à un point qui n’au­rait pas été jugé accep­table par le passé, et qui douce­ment est devenu plus fréquent au point qu’il soit consi­déré désor­mais comme « normal ».

Ce n’est pas un cas isolé. À mon arrêt de métro il y avait la place pour trois guichets de vente et conseil. Je suppose qu’à un moment il y avait eu trois personnes ou qu’au moins ça avait été envi­sagé. Je l’ai vu avec deux deux personnes aux heures de pointes, puis c’est passé à une seule. Par la suite ils ont fait des travaux et il n’y a plus physique­ment qu’un seul guichet. Au fur et à mesure plusieurs employés se sont mis à refu­ser de vendre et ne faisant plus que le conseil et redi­ri­geant vers les machines. Main­te­nant cet employé unique est aussi le gérant de la station donc souvent absent du guichet et inac­ces­sible en cas de besoin. Je crois même avoir vu une station sans aucun guichet où on conseille désor­mais de se rendre à une autre station si on a besoin de quelqu’un. Tout ça en cinq ans à peine.

Pour La Poste c’est pareil. Je ne parle pas que du temps d’at­tente mais aussi du nombre d’agences en dimi­nu­tion, des horaires qui se réduisent, du nombre de tour­nées qui est passé de trois histo­rique­ment sur Paris à deux, puis à une seule. Main­te­nant on me donne même des avis de passage pré-remplis sans sonner à l’in­ter­phone pour tenter de me remettre le colis ou le recom­mandé. On entend aussi des gens parler de facteurs qui font parfois des demies tour­nées en stockant le cour­rier non impor­tant de l’autre moitié pour le donner le lende­main. Je ne serai pas étonné d’en­tendre demain La Poste propo­ser une tour­née un jour sur deux seule­ment pour les cour­riers simples des parti­cu­liers.

On peut malheu­reu­se­ment multi­plier faci­le­ment les exemples dans tous ou presque les services publics qui ont un accueil.

De la source du problème

Il ne s’agit pas de critiquer la prise en charge ou de prétendre réor­ga­ni­ser l’hô­pi­tal. Sans aucun doute possible, d’autres aspects du trai­te­ment des urgences ont sensi­ble­ment progressé dans le même temps : la tech­ni­cité, l’ef­fi­ca­cité, ou le nombre de problèmes couverts par exemple. Très proba­ble­ment la néces­sité de cette attente augmen­tée découle d’un choix poli­tique d’af­fec­ta­tion de moyens finan­ciers ou humains, ou de prio­ri­tés dans l’uti­li­sa­tion de ces moyens.

Je ne connais pas le domaine, la cause peut être autre (ou multiple) dans le cas des urgences. Par contre que ce problème de régres­sion soit géné­ral m’in­cite à penser que c’est aussi un choix de société. C’est un choix non expli­cite, proba­ble­ment non subi et non souhaité, mais un choix tout de même.

Voici la ques­tion qui résonne encore chez moi : Depuis quand est-ce accep­table ?

Impli­ci­te­ment : Est-ce réel­le­ment une bonne chose, ne pour­rions-nous pas faire d’autres choix pour notre service public ?


Si vous voulez discu­tez de la perti­nence de mon exemple d’ur­gence, de ce qu’est une urgence, de la justi­fi­ca­tion des heures d’at­tente ou de leur légi­ti­mité, il y aura un autre billet. Merci de rete­nir vos commen­taires à ce sujet pour ne pas mélan­ger les réflexions.

Catégories
Identité numérique

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.

Catégories
Droit d'auteur Juridique

Filmer au cinéma

Je me suis toujours inter­rogé sur les inter­dic­tions de photo­gra­phier ou filmer et leur fonde­ment juri­dique. C’est vrai dans les spec­tacles, les ciné­mas ou les musées.

J’ai croisé beau­coup de billets qui expliquent pourquoi c’est mal, pourquoi c’est bien, pourquoi ça fait mourir les artistes ou au contraire pourquoi ça les aide­rait à vivre, mais tous jouent sur des argu­ments de légi­ti­mité morale.

Ce qui m’in­té­resse ce n’est pas savoir si c’est normal ou souhai­table, mais c’est si c’est légal : « Ai-je le droit ? » et « A-t-on le droit de me l’in­ter­dire ? ».

Fonde­ments juri­diques

Concer­nant le droit d’au­teur, l’ex­cep­tion de copie privée empêche l’au­teur de m’in­ter­dire la copie (et donc l’en­re­gis­tre­ment). Affir­mer que tech­nique­ment je pour­rai en faire une diffu­sion illé­gale ne peut justi­fier léga­le­ment qu’on m’in­ter­dise la copie privée elle-même.

Restent donc les règle­ments inté­rieurs et les condi­tions géné­rales de vente ou d’uti­li­sa­tion des lieux ou services donnant accès aux œuvres.

Je n’ai pas la connais­sance juri­dique pour tran­cher mais cela m’a toujours semblé un argu­ment bancale. S’il suffit de condi­tions géné­rales pour empê­cher la copie, alors ça revient à dire que l’ex­cep­tion de copie n’a aucune valeur : Tous les exploi­tants vont mettre une inter­dic­tion à ce niveau. Ils le font d’ailleurs déjà.

En fait quand je lis les condi­tions d’un DVD j’ai même l’im­pres­sion de ne pas avoir le droit d’in­vi­ter un ami pour le regar­der. Heureu­se­ment je ne suis pas tenu d’ap­pliquer ce que léga­le­ment ils ne peuvent m’im­po­ser.

Bref, en atten­dant j’ai consi­déré que l’ex­ploi­tant d’un lieu ou d’un service pouvait restreindre à peu près ce qu’il voulait (donc la copie), mais pour moi la ques­tion restait encore ouverte.

Photo­gra­phier dans les musées

Aujourd’­hui je tombe juste­ment sur un article qui parle de la ques­tion concer­nant les musées. L’au­teure est juriste en droit des affaires et droit d’au­teur, a publié plusieurs guides juri­diques chez Dalloz, et enseigne le droit d’au­teur en univer­sité. Son avis peut donc proba­ble­ment être consi­déré comme rensei­gné.

Je retire de cette lecture que juste­ment, rien ne permet à un musée d’in­ter­dire de prendre des photo­gra­phies si cela ne pose pas de trouble anor­mal comme abîmer les œuvres ou bloquer le musée. Anne-Laure Sterin rappelle que le droit de propriété de l’ex­ploi­tant n’est pas absolu et selon elle il ne peut être invoqué pour empê­cher la prise de vue. Bref, il ne suffit pas de gérer le lieu pour avoir le droit d’ajou­ter l’in­ter­dic­tion, il faut en plus la légi­ti­mer.

Et dans les cinéma ?

Si un musée ne peut le faire, qu’est-ce qui permet à un cinéma ou un spec­tacle d’agir diffé­rem­ment tant qu’on ne trouble pas la repré­sen­ta­tion ?

Je ne vois pas de réponse légale, mais comme juste­ment ce n’est pas mon domaine d’ex­per­tise, vous êtes bien­ve­nus à éclair­cir ce point. En l’at­tente, j’au­rai tendance à consi­dé­rer qu’il n’y a pas de base légale à ses inter­dic­tions, et qu’elles n’en­gagent donc que ceux qui souhaitent les respec­ter.

N’ou­bliez pas : On ne cherche pas une loi qui auto­ri­se­rait la copie ou l’en­re­gis­tre­ment. Tout ce qui n’est pas expli­ci­te­ment inter­dit est auto­risé. C’est un texte légis­la­tif ou régle­men­taire qui inter­dit (ou permet à quelqu’un d’in­ter­dire) que je recherche.


Comme il s’agit d’un sujet passion­nel, je rappelle qu’il s’agit d’une ques­tion théo­rique. Droit ou pas, il est probable que celui qui cherche à filmer dans un cinéma se fasse expul­ser manu mili­tari et passe une mauvaise soirée, en plus de gêner tout le monde s’il tente de résis­ter ou argu­men­ter sur place. Ce n’est donc aucu­ne­ment un encou­ra­ge­ment à enre­gis­trer, quand bien même ce serait légal.

De même ce n’est pas non plus un soutien à la diffu­sion illé­gale de conte­nus sous droits d’au­teur. Même si la copie privée peut être auto­ri­sée, ce n’im­plique pas un droit de diffu­sion. Il s’agit simple­ment de curio­sité intel­lec­tuelle et je n’ai pas l’en­vie de d’avoir un débat sur les ques­tions de P2P, de révo­lu­tion numé­rique, de modèle écono­mique ou de morale. Tout ce qui part en ce sens passera à la trappe sans aver­tis­se­ment.

Catégories
Méthodes agiles

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.

Catégories
Développement web

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.

Catégories
Blog et vie du site

Les commen­taires c’est moche

Je suis très insa­tis­fait par mes commen­taires.

Il y a d’abord un problème tech­nique. Disqus est perfec­tible sur de nombreux points et n’aide pas les gens à obte­nir des commen­taires agréables à lire. Ce sera changé.

Par contre j’ai suis aussi assez frus­tré par le contenu. Je n’y trouve pas mon compte. Cela donne des commen­taires à rallonge qui me semblent gêner la place que je souhaite donner au billet initial. De plus on a des discus­sions qui sont diffi­ciles à lire, et que je ne juge pas tout à fait en contexte. En fait si j’étais moi visi­teur j’ai l’im­pres­sion que lire les commen­taires me donne­rait l’im­pres­sion de perdre mon temps et m’in­ci­te­rait à ne pas reve­nir sur le site.

Pour­tant j’y tiens à ces commen­taires et je remer­cie ceux qui les font. Même quand je trouve que c’est n’im­porte quoi, je suis heureux que quelqu’un me dise qu’il n’est pas d’ac­cord (même si je suis frus­tré quand il ne m’ex­plique pas assez le pourquoi de ce désac­cord). Il s’agit donc d’après moi d’abord d’un problème de présen­ta­tion.

Je ne souhaite pas les reti­rer mais je trouve indis­pen­sable de les faire évoluer. Voici quelques pistes et je veux bien … vos commen­taires juste­ment :

  1. Pour isoler la zone de commen­taires du billet
    1. Replier la zone de commen­taire par défaut (il faudra un clic pour la déplier)
      1. … mais on la garde dépliée par défaut pour ceux qui l’ont déjà ouverte sur le même billet
      2. … mais on la garde dépliée par défaut pour ceux qui ont déjà commenté le même billet
      3. … mais on la garde dépliée par défaut pour ceux qui l’ont déjà dépliée sur un billet du blog et qu’ils ne l’ont pas repliée depuis
      4. … mais on laisse quelques commen­taires choi­sis (par moi ou par popu­la­rité) déplié de toutes façons
    2. Exter­na­li­ser les commen­taires sur une page sépa­rée (en popup ou non)
  2. Éviter les commen­taires à rallonge illi­sibles
    1. Limi­ter la taille des commen­taires
    2. Replier par défaut les commen­taires long (il faudra cliquer pour voir plus que les premières lignes)
      1. Déplier commen­taire par commen­taire lors d’un clic
      2. Déplier tous les commen­taires long d’un coup
    3. Propo­ser aux gens qui répondent à plusieurs points / argu­ments / idées d’un billet de faire un commen­taire pour chaque
    4. Propo­ser une zone de commen­taire par point / titre / argu­ment du billet (géré auto­ma­tique­ment avec la hiérar­chie des titres du billet)
    5. Replier par défaut les discus­sions (on ne laisse que le ou les premiers commen­taires de chaque fil de discus­sion)
  3. Éviter les discus­sions à rebond
    1. Reti­rer toute hiérar­chie dans les commen­taires (on répond sous la file et pas à un commen­taire parti­cu­lier)
    2. Avoir une hiérar­chie simple (un commen­taire commence un fil de discus­sion mais on ne peut pas créer de sous-fil de discus­sion), comme actuel­le­ment
    3. Augmen­ter la hiérar­chie dans les commen­taires (on répond à un commen­taire parti­cu­lier en créant un nouveau fils)
    4. Modé­rer à la hache quand je ne trouve pas les commen­taires perti­nents
  4. Éviter les commen­taires que je juge hors contexte (sur un point annexe et pas sur le fond de la discus­sion)
    1. Modé­rer à la hache
    2. Lais­ser faire
    3. M’au­to­ri­ser à modi­fier les commen­taires des autres pour ne lais­ser que ce qui me semble perti­nent (aie)
    4. Faire deux zones de commen­taires et migrer manuel­le­ment certains commen­taires vers la secondes (commen­taires hors contexte, peu perti­nents, etc) qui sera repliée par défaut ou sur une page annexe
    5. Ajou­ter en bas des billets clai­re­ment les sujets que j’at­tends dans les commen­taires

J’ai utilisé des numé­ros pour faci­li­ter les discus­sions, donc n’hé­si­tez pas à dire que vous parlez du point 2.2.1 .. ou en ajou­ter d’autres.

Catégories
Développement web

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.