Je ne demande pas aux gens de faire l’impossible. Je leur demande juste d’essayer.
Auteur/autrice : Éric
-
Le web ouvert recule
On se gargarise de HTML 5 ou CSS 3, on idéalise Wikipedia et Creative Commons, mais côté web ouvert soyons clairs : Nous reculons, et à marche forcée. Ça devient d’autant plus préoccupant que même les plus geeks ne font plus que des déclarations de principe sur le sujet, sans le soutenir par des actions et réalisations.
En quelques jours DailyMotion abandonne OpenID, Google lance Google+ et TweetDeck abandonne son support pour StatusNet. Même les projets libres ne font plus que le minimum syndical de ce côté là. C’est une tendance de fond, sous prétexte de simplification de l’expérience utilisateur.
Ce n’est pas un problème de geek
Je ne suis pas d’accord avec ceux qui prétendent que c’est un problème de geek. Ces préoccupations sont déjà à l’esprit des utilisateurs « non experts » :
- Suis-je obligé de rester si je ne veux pas perdre mes données, mon adresse ou mes connexions ?
- Puis-je communiquer avec des personnes sur des services tiers ?
- Pourquoi ai-je besoin de gérer 15 identifiants 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’esprit. Certains ont même déjà des expériences douloureuses de changement d’adresse (email du FAI), de communiquer avec des relations qui sont sur deux plateformes différentes et incompatibles, ou de migration de données.
Le tout c’est de ne pas aborder l’angle technique, qui lui effectivement n’intéresse que le geek. Décentralisé ? c’est quoi qu’est-ce ?
Diaspora ? Jabber ? StatusNet ? aucun intérêt
Si rien n’avance, c’est que ce que nous proposons en alternative n’a que peu d’intérêt. En proposant un remplaçant décentralisé à Facebook ou à MSN ce qu’on propose c’est de réaliser maintenant et volontairement l’apocalypse dont on cherche à se protéger pour plus tard : perte des données, de son adresse, de ses relations, et des interactions avec le reste du monde.
C’est même encore moins intéressant puisque les services alternatifs sont souvent moins aboutis et n’auront d’intérêt que si on réussit aussi à faire migrer toutes ses relations (et qu’elles aussi y réussissent), ce qui n’arrivera pas.
Même ceux qui n’ont pas encore de compte, donc pas de donnée ou d’adresse à perdre, n’ont pas vraiment 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éologie ou par conviction, pas pour des raisons pratiques et pragmatiques.
Gérer son identité
Il nous faut pourtant avancer et pour cela nous avons deux options : Créer le nouveau service ultime qui accueillera tous les utilisateurs, en le faisant « bien » selon nos critères de liberté, de contrôle de son identifiant, de vie privée, etc. ou s’occuper de la brique fondamentale qui nous pose problème : la gestion d’identité.
J’ai besoin d’une brique pour gérer ce qui suit :
- Annoncer et prouver mon identité
- Présenter des informations différentes en fonction de mon interlocuteur
- Accéder aux informations que les autres me partagent
- Déléguer un service à un tiers tout en gardant le contrôle sur mon identifiant
- Avoir un identifiant simple, mémorisable et manipulable par tous
Si j’ai ça ensuite on pourra brancher des services unitaires dessus sans avoir à remplacer Facebook en entier.
Du mieux
Mais surtout, pour que ça fonctionne, il faut présenter mieux que l’existant. Nous devons avoir un plus fonctionnel immédiat à proposer. Cet intérêt ne doit pas être simplement un intérêt technique ou à long terme.
-
Non il n’y a pas pénurie d’informaticiens
Pitié, arrêtons avec ça. On nous a déjà fait le coup plusieurs fois. Remettons de l’ordre dans les légendes urbaines en utilisant des indicateurs objectifs et pas du ressenti publiés par des gens qui y ont intérêt.
L’informatique n’est pas en pénurie
La tension du marché est caractérisée par le ratio entre les offres et les demandes. Il y a 25 % moins d’offres que de demandes. C’est d’autant plus significatif que nous avons un domaine avec quelques spécificités comme un turn-over deux fois plus important que la moyenne et des annonces de recrutement permanentes sur tous les sites de recrutement pour alimenter des bases de profils.
Nous avons 1 création de poste pour 4 recrutements 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 informatiques que d’offres d’embauche pour ces primo-demandeurs. Si ça c’est une pénurie, il faudra m’expliquer.
L’informatique a un taux de chômage conséquent
Le chômage des informaticiens a même monté de 45 % sur 2009 si on prend en compte les primo-demandeurs, après 7 mois successif 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 structurel 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’euphorie qu’on a nommé après « la bulle Internet », qu’il est difficile de considérer comme représentatives de la réalité ou de l’avenir.
C’est d’autant plus significatif que 75 % des salariés du secteur sont des cadres, habituellement moins touchés par le chômage. Le secteur n’est pas en pénurie, mais il n’est pas tellement mieux loti que le reste non plus. Il est par exemple factuellement moins porteur que l’agriculture (surtout si on compare au domaine « études et recherche »).
L’embauche en informatique n’est pas si difficile
Nous n’avons pas de pénurie, nous avons même un chômage structurel. Alors, avons-nous au moins des difficultés de recrutement exceptionnelles ?
L’APEC a deux statistiques intéressantes à ce niveau. Elle mesure un indicateur de difficulté d’embauche. Cet indicateur est dans notre secteur de 22 % pour les cadres et de 5 % pour les non-cadres. Il est à comparer à 20 % pour l’ensemble du secteur tertiaire. Nous n’avons donc pas de difficulté exceptionnelle pour les cadres, et une grande facilité pour les non-cadres. Pour référence le même indicateur est de 56 % dans l’industrie du bâtiment et de 28 % pour l’industrie manufacturière.
Le second indicateur mesure l’adéquation des embauchés par rapport aux attentes. L’APEC nous indique que 92 % des recruteurs estiment que l’écart entre le profil recherché et celui de la personne recrutée est nul ou faible.
Bref, recruter est difficile, surtout pour un travail intellectuel. C’est vrai en informatique comme ailleurs, mais pas plus qu’ailleurs, et pas à cause d’une soi-disante pénurie.
Il n’y a pas de tensions sur les salaires en informatique
Cette absence de tension réelle se voit d’ailleurs sur les salaires. Étrangement si la statistique précédente nous dit que les profils recrutés sont à 92 % conformes aux attentes, la même statistiques nous dit aussi que 85 % des salaires à l’embauche sont équivalents ou inférieurs à ceux envisagés.
Les salaires vont plutôt à la baisse par rapport aux attentes initiales sans que ce ne soit justifié par des profils moins compétents que prévu. Ce n’est pas réellement le reflet d’une difficulté à recruter.
Pourtant ces mêmes salaires sont déjà bas. L’activité « études, développement et intégration » a le 32ème salaire médian sur les 36 référencées, juste avant « études techniques et essais », « conception », « recherche fondamentale » et « autre enseignement ». Ce n’est pas là non plus le reflet d’un marché en tension.
Entre septembre 2010 et mars 2011 les salaires à l’embauche des cadres a augmenté de 2,9 % tous secteurs confondus, sans qu’on ne parle de pénurie. En informatique et telecom, il n’a été que de 0,4 % : 7 fois moins.
Que cette question du salaire soit la source de la difficulté de recrutement ou le signe de son absence relève de l’interprétation, mais en tous cas ça ne colle pas avec un marché en tension et en pénurie.
Mais alors, quel est le problème en informatique ?
Là nous entrons dans la partie d’opinion alors que le reste était basé sur des chiffres objectifs. Je réserve donc ça pour un billet séparé. Pour faire court ça tient tout de même en quelques points : SSII, activité cyclique et évolution de carrière.
-
Bon chasseur et mauvais chasseur : architectures et données personnelles
Pour protéger les données des utilisateurs il y a des bonnes architectures et des mauvaises architectures.
C’est aussi simple que cela. Ne vous laissez pas dire que tous les systèmes sont faillibles, qu’il y a de bonnes raisons, ou que ce n’est pas important. C’est vrai, mais il reste que votre architecture peut être bonne ou mauvaise. Ça aura un impact un jour ou l’autre, plus rapidement que vous ne l’espérez.
Stocker en clair c’est mal
Des gens meilleurs que vous s’y sont laissés prendre. Des sociétés solides se sont faites avoir. Y compris des gens qui avaient de bonnes raisons techniques ou fonctionnelles de faire ainsi.
Rien ne change, si vous stockez les mots de passe en clair (ou de façon déchiffrable), un jour une faille logicielle ou système y donnera accès et vous aurez un gros problème avec vos utilisateurs.
Dans le meilleur des cas vous serez prévenus rapidement et vous aurez juste une très mauvaise publicité comme Sony récemment, 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 juridiques, financiers et humains insolvables.
Ne pas utiliser SSL / TLS pour les communications réseau c’est mal
Des gens meilleurs que vous s’y sont laissés prendre. Des sociétés plus solides se sont faites avoir. Ai-je besoin de tout répéter ?
Si vous ne chiffrez pas toutes les communications réseau avec vos clients dès que vous transférez des données sensibles, vous prenez un risque important pour la sécurité des dites données. Chiffrer uniquement la phase d’authentification ne suffit pas, quoi qu’on vous dise.
Vos utilisateurs ont besoin d’une connexion sécurisée. Tout le reste n’est que bidouillage et mauvaise architecture. Tôt ou tard il y aura un abus d’un état, d’un FAI, d’une entreprise, d’une école, qui aura un peu de publicité et qui vous posera un problème important.
Chiffrer avec la clef de déchiffrage 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.
Chiffrer et déchiffrer sur le serveur en laissant la clef sur place, c’est comme avoir une porte blindée avec serrure trois points et laisser 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.
Dropbox avait fait de la publicité autour de la sécurité de leur service. Ils avaient une unique clef de chiffrage, sur leur serveur. Les utilisateurs ont râlé, fait de la mauvaise publicité, et même porté plainte. D’aucuns ont dit que ce n’était pas important.
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 partager avec Dropbox.
Les râleurs n’avaient pas de boule de cristal, ce qui est arrivé était évident. On savait que ça arriverait, et on peut dire que les conséquences ont été les extraordinairement faibles par rapport aux risques. La prochaine fois ce sera bien plus gênant.
Quelle que soit la raison, une mauvaise architecture reste mauvaise
Il se peut qu’on soit obligé d’utiliser une mauvaise architecture. Il se peut que cette mauvaise architecture soit un compromis acceptable, ou même souhaitable en fonction de besoin spécifiques.
C’est rare, tout le monde a tendance à se penser dans le cas exceptionnel alors que ce n’est pas le cas, mais ça peut arriver. Mais, même dans ce cas, il ne faut pas perdre de vue que ça reste une mauvaise architecture, et qu’on en subira les conséquences.
Il y a des bonnes et des mauvaises architectures, c’est ainsi. Faites ce que vous pensez le mieux, il se peut que vous ayez de bonnes raisons de choisir la mauvaise architecture (même s’il y a toutes les chances que vous fassiez erreur). Mais quelles que soient ces raisons, elles ne transformeront pas votre mauvaise architecture en « bonne » architecture. Vous venez de choisir une mauvaise architecture pour de bonnes raisons, voilà tout. Et vous allez le payer.
-
Depuis quand est-ce normal ? – service public
Depuis quand est-ce acceptable d’attendre 4 à 7 heures aux urgences d’un hôpital ?
Si la question n’est pas de moi elle résonne très bien dans mon esprit. Ça aurait certainement pu arriver il y a 30 ans, mais je ne crois sérieusement pas que cela aurait été considéré comme « normal ».
Le tour de force
Quand j’ai posé la question autour de moi on m’a parlé catégorisation des urgences, de priorisation, de la surcharge des services avec des urgences non vitales, de ce que devrait être le travail d’un médecin urgentiste, de la possibilité de donner des anti-douleurs pour aller voir le lendemain son médecin généraliste quand ce n’est pas vital, etc.
Au final toutes ses réponses reviennent au même dans mon esprit : Nous catégorisons et nous justifions la baisse de qualité du service globale par la nécessité de traiter correctement la catégorie la plus vitale.
Cela revient simplement à dire que nous manquons de moyen pour traiter tout le monde correctement. Le tour de force communicationnel est d’être arrivé à ce que les conséquences de ce manque de moyen soit considéré comme « normal ».
Non ce n’est pas normal
Parce que non ce n’est pas normal. Que ça puisse arriver exceptionnellement à cause d’une affluence imprévisible je ne le nie pas. Que ce soit fréquent ou normal ça je ne peux pas être d’accord.
S’il y a du mauvais routage il doit être détecté et renvoyé ailleurs lors de l’accueil. Bien évidemment il n’est pas acceptable qu’un service d’urgence mette plusieurs heures avant de qualifier une arrivée. Visiblement ça arrive tout de même.
Expérience perso: j’ai attendu 4h une radio qui détecta un pneumothorax. Je suis passé de l’étiquette verte au bloc opé en 10min — Cyprien
Il n’est pas non plus normal d’attendre plusieurs heures après ce premier tri. Si le cas est jugé « retournez chez vous » ou « prenez rendez vous chez votre médecin pour la semaine prochaine » alors la question 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 probablement pas acceptable et ne doit donc pas être « normal » (dans le sens « non exceptionnel).
De la dégradation du service public
Vraisemblablement le délai d’attente aux urgence s’est allongé à un point qui n’aurait pas été jugé acceptable par le passé, et qui doucement est devenu plus fréquent au point qu’il soit considéré désormais 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é envisagé. 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 physiquement qu’un seul guichet. Au fur et à mesure plusieurs employés se sont mis à refuser de vendre et ne faisant plus que le conseil et redirigeant vers les machines. Maintenant cet employé unique est aussi le gérant de la station donc souvent absent du guichet et inaccessible en cas de besoin. Je crois même avoir vu une station sans aucun guichet où on conseille désormais 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’attente mais aussi du nombre d’agences en diminution, des horaires qui se réduisent, du nombre de tournées qui est passé de trois historiquement sur Paris à deux, puis à une seule. Maintenant on me donne même des avis de passage pré-remplis sans sonner à l’interphone pour tenter de me remettre le colis ou le recommandé. On entend aussi des gens parler de facteurs qui font parfois des demies tournées en stockant le courrier non important de l’autre moitié pour le donner le lendemain. Je ne serai pas étonné d’entendre demain La Poste proposer une tournée un jour sur deux seulement pour les courriers simples des particuliers.
On peut malheureusement multiplier facilement 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éorganiser l’hôpital. Sans aucun doute possible, d’autres aspects du traitement des urgences ont sensiblement progressé dans le même temps : la technicité, l’efficacité, ou le nombre de problèmes couverts par exemple. Très probablement la nécessité de cette attente augmentée découle d’un choix politique d’affectation de moyens financiers ou humains, ou de priorités dans l’utilisation 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égression soit général m’incite à penser que c’est aussi un choix de société. C’est un choix non explicite, probablement non subi et non souhaité, mais un choix tout de même.
Voici la question qui résonne encore chez moi : Depuis quand est-ce acceptable ?
Implicitement : Est-ce réellement une bonne chose, ne pourrions-nous pas faire d’autres choix pour notre service public ?
Si vous voulez discutez de la pertinence de mon exemple d’urgence, de ce qu’est une urgence, de la justification des heures d’attente ou de leur légitimité, il y aura un autre billet. Merci de retenir vos commentaires à ce sujet pour ne pas mélanger les réflexions.
-
Identifiant utilisateur et message d’erreur
L’utilisateur ou le mot de passe fournis est invalide
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 utilisateur à jeter
Malheureusement, comme tout le monde, je n’ai pas pu ou voulu avoir le même identifiant utilisateur 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’erreur rend plus difficile de rentrer sur le compte. En tout cas c’est vrai pour l’utilisateur légitime. Ce qui aurait pu lui permettre de s’identifier en quelques minutes lui prendra un bon quart d’heure le temps de tester toute une combinaison d’identifiants utilisateur et la croiser avec autant de mots de passe.
L’identifiant utilisateur n’est pas une sécurité
La raison d’être de ce message est souvent un développeur qui a souhaité améliorer la sécurité. Le fondement est logique, si l’identifiant utilisateur est une inconnue, cela fait une entrée de plus à forcer ou deviner.
Mais en même temps, si en connaissant l’identifiant utilisateur il est possible de forcer le compte relativement simplement, vous avez un vrai problème, et ce problème ne vient pas de l’identifiant utilisateur. Vous venez d’ajouter de cacher le cadenas parce qu’il est trop simple à forcer quand on le trouve. Est-ce réellement la bonne approche ?
Trouver un identifiant utilisateur est simple
S’il s’agit de tester des identifiants communs à l’aide d’un dictionnaire et que nous parlons d’un service grand public, ne nous voilons par la face : Nous savons que « bob », « bob75 » et « greatbob » existent. Il n’est pas besoin de les tester. C’est même à cause de cette pré-existence extrêmement probable que vos utilisateurs ont des identifiants différents partout.
Si à l’inverse vous visez un utilisateur particulier, si vraiment l’ingénierie sociale n’est d’aucune aide à l’attaquant (ce qui serait étonnant), il lui restera à tester quelques variantes les plus probables dans votre robot. Ce qui est extrêmement pénible à faire pour un humain ne changera pas l’ordre de grandeur du problème pour le robot et ne rendra pas beaucoup plus ou beaucoup moins fiable votre système.
Pire, si vraiment il s’agit de découvrir l’existence d’un identifiant, et si vous tentiez une création de compte avec l’identifiant en question ? On ne vous dit pas si l’identifiant est disponible à ce moment là ? Était-ce bien la peine de complexifier l’expérience utilisateur d’un côté si l’information est disponible facilement ailleurs ?
Votre sécurité est ailleurs
Vous voulez augmenter la sécurité ? imposez un mécanisme de double authentification, un nombre d’essai maximum, une temporisation d’une dizaine de secondes, des mots de passe forts, ou même deux caractères de plus dans votre mot de passe. Voilà, votre sécurité est aussi bien voire mieux assurée qu’en cherchant à donner un message d’erreur peu explicite à l’utilisateur.
Si réellement l’identifiant utilisateur était un composant de sécurité, autant le mettre en champ « mot de passe » au lieu d’avoir un champ texte en clair. Mieux, on imposerait une longueur minimale et on interdirait les identifiants courants. En allant au bout de la démarche on pourrait même faire un seul champ « utilisateur et mot de passe » puisque l’identifiant utilisateur ne sert pas à grand chose d’autre.
Je ne sais pas si vous avez vu mais on retombe sur nos pas : pour améliorer la sécurité, ajoutez des caractères au mot de passe, ne prenez pas l’identifiant utilisateur pour un mot de passe.
L’identifiant utilisateur comme donnée de valeur
Vient un dernier problème qu’on m’a soumis : Parfois l’identifiant utilisateur peut lui même être une donnée de valeur.
Je trouve dans cette catégorie des extranet dont l’identifiant utilisateur est prédictible mais où l’appartenance de l’utilisateur au système donne une information importante. Ce peut par exemple être l’extranet 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 identifiants sont non prédictibles, ça ne concerne par les récoltes anonymes (où on ne vise pas un utilisateur précis) et ça ne concerne que les cas où l’identifiant utilisateur a une valeur en soi. C’est rare, plus probablement la solution serait de rendre l’identifiant anonyme ou non prédictible, mais ce sont des cas légitimes.
Par contre, pour votre boutique en ligne, pour votre forum, non, il n’y a aucune raison de gêner l’utilisateur à ce point, vraiment.
-
Filmer au cinéma
Je me suis toujours interrogé sur les interdictions de photographier ou filmer et leur fondement juridique. C’est vrai dans les spectacles, les cinémas ou les musées.
J’ai croisé beaucoup de billets qui expliquent pourquoi c’est mal, pourquoi c’est bien, pourquoi ça fait mourir les artistes ou au contraire pourquoi ça les aiderait à vivre, mais tous jouent sur des arguments de légitimité morale.
Ce qui m’intéresse ce n’est pas savoir si c’est normal ou souhaitable, mais c’est si c’est légal : « Ai-je le droit ? » et « A-t-on le droit de me l’interdire ? ».
Fondements juridiques
Concernant le droit d’auteur, l’exception de copie privée empêche l’auteur de m’interdire la copie (et donc l’enregistrement). Affirmer que techniquement je pourrai en faire une diffusion illégale ne peut justifier légalement qu’on m’interdise la copie privée elle-même.
Restent donc les règlements intérieurs et les conditions générales de vente ou d’utilisation des lieux ou services donnant accès aux œuvres.
Je n’ai pas la connaissance juridique pour trancher mais cela m’a toujours semblé un argument bancale. S’il suffit de conditions générales pour empêcher la copie, alors ça revient à dire que l’exception de copie n’a aucune valeur : Tous les exploitants vont mettre une interdiction à ce niveau. Ils le font d’ailleurs déjà.
En fait quand je lis les conditions d’un DVD j’ai même l’impression de ne pas avoir le droit d’inviter un ami pour le regarder. Heureusement je ne suis pas tenu d’appliquer ce que légalement ils ne peuvent m’imposer.
Bref, en attendant j’ai considéré que l’exploitant d’un lieu ou d’un service pouvait restreindre à peu près ce qu’il voulait (donc la copie), mais pour moi la question restait encore ouverte.
Photographier dans les musées
Aujourd’hui je tombe justement sur un article qui parle de la question concernant les musées. L’auteure est juriste en droit des affaires et droit d’auteur, a publié plusieurs guides juridiques chez Dalloz, et enseigne le droit d’auteur en université. Son avis peut donc probablement être considéré comme renseigné.
Je retire de cette lecture que justement, rien ne permet à un musée d’interdire de prendre des photographies si cela ne pose pas de trouble anormal comme abîmer les œuvres ou bloquer le musée. Anne-Laure Sterin rappelle que le droit de propriété de l’exploitant 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’ajouter l’interdiction, il faut en plus la légitimer.
Et dans les cinéma ?
Si un musée ne peut le faire, qu’est-ce qui permet à un cinéma ou un spectacle d’agir différemment tant qu’on ne trouble pas la représentation ?
Je ne vois pas de réponse légale, mais comme justement ce n’est pas mon domaine d’expertise, vous êtes bienvenus à éclaircir ce point. En l’attente, j’aurai tendance à considérer qu’il n’y a pas de base légale à ses interdictions, et qu’elles n’engagent donc que ceux qui souhaitent les respecter.
N’oubliez pas : On ne cherche pas une loi qui autoriserait la copie ou l’enregistrement. Tout ce qui n’est pas explicitement interdit est autorisé. C’est un texte législatif ou réglementaire qui interdit (ou permet à quelqu’un d’interdire) que je recherche.
Comme il s’agit d’un sujet passionnel, je rappelle qu’il s’agit d’une question théorique. Droit ou pas, il est probable que celui qui cherche à filmer dans un cinéma se fasse expulser manu militari et passe une mauvaise soirée, en plus de gêner tout le monde s’il tente de résister ou argumenter sur place. Ce n’est donc aucunement un encouragement à enregistrer, quand bien même ce serait légal.
De même ce n’est pas non plus un soutien à la diffusion illégale de contenus sous droits d’auteur. Même si la copie privée peut être autorisée, ce n’implique pas un droit de diffusion. Il s’agit simplement de curiosité intellectuelle et je n’ai pas l’envie de d’avoir un débat sur les questions de P2P, de révolution numérique, de modèle économique ou de morale. Tout ce qui part en ce sens passera à la trappe sans avertissement.
-
Perplexité, complexité, vélocité … une autre vue
J’ai lu « Perplexité, complexité, vélocité » sur le blog d’OCTO. L’article est bien tourné et on sort complètement 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 transforment en avis contraire. Je vous encourage à lire d’abord le billet d’OCTO, le mien n’aura de sens qu’en réponse.
À quoi sert la vélocité ?
À quoi sert la vélocité ?
1. Estimer ce qui sera réalisé ou non dans le sprint
2. Mesurer la productivité de l’équipe
3. Mesurer le réalisé pour le projet, le produit
Ma divergence avec l’article source vient d’un constat simple : Nous n’utilisons pas cet indicateur dans le même objectif. Lui l’utilise pour mesurer la productivité, moi pour améliorer les estimations.
Améliorer les estimations
Améliorer les estimations c’est faire en sorte de mieux évaluer ce qui sera livré dans chaque sprint et aider à la priorisation. Bref, gérer le projet.
Pour améliorer nos estimations on tente de se baser sur les tâches similaires précédentes et on en réutilise l’estimation sans tenir compte de la productivité de l’équipe. On utilise pour cela une unité virtuelle qui nous détache des jours/hommes : le point. Réaliser une estimation ainsi est de plus en plus simple, rapide et fiable.
Pour prendre en compte les évolutions de productivité (équipe plus efficace ou dette technique grandissante) c’est le nombre de points réalisable 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’estimation sont stables, nos estimations se fiabilisent avec le temps. Le nombre magique de points qu’on peut mettre dans un sprint, c’est pour moi ce qu’est la vélocité de l’équipe.
En prenant en compte la technique
Si on calcule en points et pas en heures ou en jours, ce n’est pas parce qu’on compte en complexité fonctionne, c’est pour s’autoriser à faire varier la somme totale plutôt que chaque estimation.
Il ne faut pas perdre de vue que notre objectif reste bien d’évaluer une charge de développement. Il faut donc tenir compte dans nos estimations de tout ce qui est nécessaire à évaluer le temps de développement et livrer la fonctionnalité : Ça va des besoins fonctionnels à la complexité technique en passant par les contraintes organisationnelles spécifiques.
Si je ne prends en compte que la complexité fonctionnelle, l’estimation n’aura plus aucun lien avec le temps de développement. Pour savoir ce qui tient ou pas dans le sprint, on en viendra à faire une estimation globale, au jugé, sans références similaires : tout l’inverse de l’objectif.
Outil privé versus indicateur public
À mon humble avis l’erreur de l’article n’est pas seulement de faire de la vélocité une mesure de productivité, c’est en plus de l’avoir communiquée à l’extérieur de l’équipe.
Du coup, forcément, la vélocité devient un enjeu politique. L’équipe, son manager, son coach commencent à avoir intérêt à améliorer l’indicateur au lieu de se concentrer sur ce qui devrait être leur seul objectif : apporter de la valeur au produit.
Que la vélocité augmente, diminue, c’est quelque chose propre à l’équipe. S’il faut un indicateur de productivité et de perturbation, il faut publier la seule chose importante : la progression de la valeur du produit (si ça ressemble au paragraphe précédent, ce n’est pas une coïncidence).
Cette vélocité doit être prise pour ce qu’elle est : un outil d’estimation, de planification et de priorisation. Comme tous les outils, il a vocation à être utilisé en interne, par l’équipe, et nulle part ailleurs.
Et la complexité fonctionnelle ?
Mon second problème est là : Selon moi la complexité fonctionnelle n’indique rien de valable. Ce n’est pas une mesure de ce que coûte la fonctionnalité, ce n’est pas une mesure de ce qu’apporte la fonctionnalité, et incidemment ce n’est pas une mesure de l’implication ou de la productivité de l’équipe.
Tout au plus la complexité fonctionnelle permet de faire une première estimation des histoires utilisateurs qui ne sont pas prévues pour tout de suite ou dont on ne connaît pas la complexité technique.
-
Résolutions d’écran – mai 2011
Petite statistiques absolument pas représentative mais intéressante quand même : les résolutions d’écran des gens qui sont passés sur ce site du 1 au 12 mai 2011.
Petite interprétation perso :
- J’ai moins de 10% de visites de mobile (résolution inférieure à 1024px)
- Je dois avoir environ 3% de netbook et tablettes (résolution de 1024px mais pas plus)
- Les desktop supportent tous ou presque au moins 1280px (87% de support, mobiles inclus)
- Les mobiles sont tous différents et il est difficile d’acter d’une résolution minimale standard sauf à la prendre vraiment très petite
- Une version minimale à 240 ou 280px, quitte à ce qu’elle soit très dégradée
- Une version à 800 (android récent en paysage), qui servira aussi pour les iphone avec une meilleure résolution, les tablettes et les netbooks
- Une version desktop à 1280, qui sera la version « standard »
- Une à 1400 ou 1600 pour récupé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
-
Les commentaires c’est moche
Je suis très insatisfait par mes commentaires.
Il y a d’abord un problème technique. Disqus est perfectible sur de nombreux points et n’aide pas les gens à obtenir des commentaires agréables à lire. Ce sera changé.
Par contre j’ai suis aussi assez frustré par le contenu. Je n’y trouve pas mon compte. Cela donne des commentaires à rallonge qui me semblent gêner la place que je souhaite donner au billet initial. De plus on a des discussions qui sont difficiles à lire, et que je ne juge pas tout à fait en contexte. En fait si j’étais moi visiteur j’ai l’impression que lire les commentaires me donnerait l’impression de perdre mon temps et m’inciterait à ne pas revenir sur le site.
Pourtant j’y tiens à ces commentaires et je remercie ceux qui les font. Même quand je trouve que c’est n’importe quoi, je suis heureux que quelqu’un me dise qu’il n’est pas d’accord (même si je suis frustré quand il ne m’explique pas assez le pourquoi de ce désaccord). Il s’agit donc d’après moi d’abord d’un problème de présentation.
Je ne souhaite pas les retirer mais je trouve indispensable de les faire évoluer. Voici quelques pistes et je veux bien … vos commentaires justement :
- Pour isoler la zone de commentaires du billet
- Replier la zone de commentaire par défaut (il faudra un clic pour la déplier)
- … mais on la garde dépliée par défaut pour ceux qui l’ont déjà ouverte sur le même billet
- … mais on la garde dépliée par défaut pour ceux qui ont déjà commenté le même billet
- … 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
- … mais on laisse quelques commentaires choisis (par moi ou par popularité) déplié de toutes façons
- Externaliser les commentaires sur une page séparée (en popup ou non)
- Replier la zone de commentaire par défaut (il faudra un clic pour la déplier)
- Éviter les commentaires à rallonge illisibles
- Limiter la taille des commentaires
- Replier par défaut les commentaires long (il faudra cliquer pour voir plus que les premières lignes)
- Déplier commentaire par commentaire lors d’un clic
- Déplier tous les commentaires long d’un coup
- Proposer aux gens qui répondent à plusieurs points / arguments / idées d’un billet de faire un commentaire pour chaque
- Proposer une zone de commentaire par point / titre / argument du billet (géré automatiquement avec la hiérarchie des titres du billet)
- Replier par défaut les discussions (on ne laisse que le ou les premiers commentaires de chaque fil de discussion)
- Éviter les discussions à rebond
- Retirer toute hiérarchie dans les commentaires (on répond sous la file et pas à un commentaire particulier)
- Avoir une hiérarchie simple (un commentaire commence un fil de discussion mais on ne peut pas créer de sous-fil de discussion), comme actuellement
- Augmenter la hiérarchie dans les commentaires (on répond à un commentaire particulier en créant un nouveau fils)
- Modérer à la hache quand je ne trouve pas les commentaires pertinents
- Éviter les commentaires que je juge hors contexte (sur un point annexe et pas sur le fond de la discussion)
- Modérer à la hache
- Laisser faire
- M’autoriser à modifier les commentaires des autres pour ne laisser que ce qui me semble pertinent (aie)
- Faire deux zones de commentaires et migrer manuellement certains commentaires vers la secondes (commentaires hors contexte, peu pertinents, etc) qui sera repliée par défaut ou sur une page annexe
- Ajouter en bas des billets clairement les sujets que j’attends dans les commentaires
J’ai utilisé des numéros pour faciliter les discussions, donc n’hésitez pas à dire que vous parlez du point 2.2.1 .. ou en ajouter d’autres.
- Pour isoler la zone de commentaires du billet