Carnet de notes

Catégorie : Technique

  • Toute l’es­time que je vous porte

    Toute l’es­time que je vous porte

    Comme beau­coup d’in­gé­nieurs, je suis réti­cent à donner des esti­ma­tions.

    je ne sais pas esti­mer

    Tous les jours, je résous des problèmes nouveaux, pour lesquels je n’ai encore jamais implé­menté de solu­tion.

    Si vous n’avez jamais fait d’in­for­ma­tique, mettez-vous bien ça dans la tête : Contrai­re­ment au maçon qui peut construire des dizaines de maisons, l’in­for­ma­ti­cien ne fait jamais deux fois la même chose. Il peut réuti­li­ser la solu­tion précé­dente à l’in­fini, en quelques heures. Qu’un déve­lop­peur fasse deux fois exac­te­ment la même chose est le symp­tôme d’un problème d’or­ga­ni­sa­tion.

    Si je passe plus de quelques heures, c’est qu’il y a un problème nouveau ou quelque chose de nouveau dans le problème, même si de haut il ressemble à un autre. Mon travail c’est unique­ment de créer ce qui manque, ce qui est nouveau par rapport à d’éven­tuelles solu­tions précé­dentes.

    Et pour ce nouveau, je vais devoir étudier le problème posé, proba­ble­ment décou­vrir des sous-problèmes qu’on n’ima­gi­nait pas. Je ne sais pas ce quelles diffi­cul­tés je vais rencon­trer, quelles solu­tions vont devoir être appliquées, comment les mettre en œuvre, si elles vont réus­sir ou échouer, et encore moins si le besoin racine va effec­ti­ve­ment être couvert à la fin de tout cela.

    Il y a plein de textes qui expliquent la problé­ma­tique de l’es­ti­ma­tion mais j’ai trouvé plus d’une fois que le récit de voyage de Michael Wolfe illustre très bien les enjeux avec une analo­gie que tout le monde comprend.

    vous non plus

    J’ai croisé de nombreuses personnes qui annonçaient savoir esti­mer assez correc­te­ment, et quelques unes qui semblaient effec­ti­ve­ment le faire. Vous en connais­sez peut-être aussi.

    En pratique à chaque fois qu’on y regarde de plus près, l’es­ti­ma­tion n’est pas plus juste qu’une autre. Au mieux on compense les mauvaises esti­ma­tions en jouant sur le contexte. L’es­ti­ma­tion est poten­tiel­le­ment respec­tée, mais elle n’en est pas plus juste. Et quand compen­ser ne suffit pas, on se rassure en consi­dé­rant que ça ne compte pas parce que c’est excep­tion­nel, qu’il y a une cause exté­rieure, ou en repor­tant la faute sur un tiers.

    Même les itéra­tions de la tant aimée métho­do­lo­gie SCRUM jouent sur le même registre : Donner une cible avec un enga­ge­ment permet d’avoir un peu de pres­sion sur l’équipe. C’est de la pres­sion dite « posi­tive », pour avoir envie d’at­teindre l’objec­tif.

    Au final c’est de la pres­sion tout de même, qui souvent se retrouve sur l’am­pli­tude horaire ou sur la fatigue. Quand le mana­ge­ment n’a pas une atten­tion et une culture extrê­me­ment forte sur le sujet, ça joue aussi sur une baisse de qualité ou une créa­tion de dette tech­nique. C’est humain. À défaut c’est le péri­mètre qui bouge, mais l’es­ti­ma­tion n’en est pas meilleure. Bref, on pallie la mauvaise esti­ma­tion en jouant sur le contexte.

    Si vrai­ment quelqu’un estime toujours juste à plus de 90%, sans compen­ser sur le contexte, c’est qu’il est en train de passer du temps à refaire ce qu’il a déjà fait. S’il travaille pour vous : virez-le et embau­chez quelqu’un qui saura réuti­li­ser plutôt que perdre du temps.

    même par petits lots

    Même l’es­ti­ma­tion par petits lots itéra­tifs n’est qu’une illu­sion. On estime effec­ti­ve­ment mieux des petites tâches qu’on sait perce­voir, mais c’est unique­ment parce qu’on réflé­chit déjà à la problé­ma­tique et à sa solu­tion au moment de donner l’es­ti­ma­tion.

    Par la suite on se trompe autant qu’ailleurs. On compense là aussi par l’am­pli­tude horaire, le stress de la pres­sion person­nelle, la qualité ou la dette tech­nique. C’est juste que plus la tâche est petite, plus le déca­lage probable est petit et donc moins il se voit de l’ex­té­rieur quand on regarde unitai­re­ment.

    Vous avez déjà remarqué qu’on ne fait pas tenir 8 tâches d’une heure dans une jour­née ou 5 tâches d’une jour­née dans une semaine ? Des tâches d’une heure dans une jour­née, prévoyez-en 6, moins le temps pour les réunions.

    Et des fois on a juste oublié un cas d’usage ou manqué une problé­ma­tique. Sur un lot impor­tant on aurait assumé et dérapé un peu. Sur une petite tâche le cas manqué peut prendre plusieurs fois l’es­ti­ma­tion de la tâche initiale. On en fait donc une nouvelle tâche, avec sa propre esti­ma­tion. Là aussi, l’ex­cuse du cas excep­tion­nel ou de la sortie de péri­mètre permet d’évi­ter de remettre en cause ses esti­ma­tions.

    Alors oui, les esti­ma­tions sur des petits lots ont tendance à être plus souvent respec­tées mais elles n’en sont pas beau­coup plus justes. Tout ceci n’est qu’œillères et illu­sions.

    C’est mieux – et c’est logique vu qu’on estime au fur et à mesure du projet, une fois la connais­sance acquise – mais ce n’est toujours pas bon.

    la mauvaise ques­tion

    On peut discu­ter de l’uti­lité des esti­ma­tions, de la capa­cité du genre humain à savoir donner des esti­ma­tions abso­lues. On peu aussi s’en­fon­cer dans un projet d’op­po­si­tion, scan­der #noes­ti­ma­te… mais qu’ap­por­te­rait-on comme valeur ?

    Je suis surtout agacé qu’on se pose surtout la mauvaise ques­tion. Au jour le jour je n’ai aucu­ne­ment besoin d’es­ti­mer. J’ai besoin d’ap­por­ter de la valeur. La seule ques­tion à me poser est « qu’est-ce qui amènera à priori le plus de valeur demain si je le fais aujourd’­hui ? » et mettre mes ressources dessus.

    La ques­tion n’est pas simple pour autant. J’ai besoin d’éva­luer si le niveau d’ef­fort à four­nir est rentable par rapport à la valeur ajou­tée atten­due. Ensuite j’ai besoin de prio­ri­ser les évolu­tions entre elles, en fonc­tion de la valeur et du niveau d’ef­fort.

    Sauf que juste­ment, je n’ai besoin pour ces usages que d’un ordre de gran­deur : Est-ce 10, 100 ou 1000 ? Est-ce beau­coup plus ou beau­coup moins que l’autre évolu­tion à laquelle je pense ? Tout autre détail est aussi utile qu’un para­chute pour monter sur une échelle.

    L’éva­lua­tion de la valeur atten­due subit de toutes façons les mêmes incer­ti­tudes que le niveau d’ef­fort à four­nir. Même s’il est fait à base d’une page pleine de formules, calcul de la valeur atten­due dépend parfois tota­le­ment de para­mètres esti­més au doigt mouillé, où même un ordre de gran­deur relève plus de la convic­tion que de l’es­ti­ma­tion.

    le mauvais usage

    Vous posez-vous vrai­ment la bonne ques­tion ?

    En cher­chant à savoir si votre projet dérape vous êtes simple­ment en train de regar­der s’il se conforme au plan prévu, à son esti­ma­tion. Véri­fier la vali­dité d’une esti­ma­tion ne vous appor­tera aucune valeur, surtout quand on sait dès le départ qu’elle est soumise à des aléas impré­vi­sibles.

    Pire, en impo­sant l’es­ti­ma­tion préa­lable comme indi­ca­teur, on freine l’ini­tia­tive (si je le fais, on prend un risque, même si je sais qu’il faut le faire), on freine la capa­cité de chan­ger (si on le fait, il faut recal­cu­ler le plan, re-esti­mer, négo­cier cette esti­ma­tion, expliquer le mauvais indi­ca­teur, ça ne vaut pas le coût ici, tant pis), et on oublie notre objec­tif (l’in­di­ca­teur est bon, tant pis si en fait on s’est rendu compte que ça ne créait pas la valeur atten­due et qu’il aurait fallu faire autre chose, ça aurait remis en cause le plan).

    Vous pouvez vous dire que vous saurez déjouer tout cela, rester agile et prag­ma­tique. Vous vous mentez, du moins tant que votre ques­tion sera « où est-ce qu’on en est par rapport aux esti­ma­tions ? ».

    C’est encore pire si vous utili­sez l’es­ti­ma­tion comme métrique pour appré­cier l’ef­fi­ca­cité ou la compé­tence de l’équipe de produc­tion. Là non seule­ment vous compa­rez juste des choux et des carottes, mais en plus vous inver­sez votre résul­tat : Ce sont des équipes qui respectent toutes leurs esti­ma­tions que vous devriez avoir peur. Elles masquent leurs erreurs en les compen­sant, volon­tai­re­ment ou non, et ça faus­sera toutes vos analyses sur la produc­tion passée ou future.

    arrê­ter de navi­guer dans le passé

    Les méthodes agiles vont dans le bon sens mais il est trop facile de s’ar­rê­ter aux arte­facts sans en comprendre l’objec­tif. Le prin­cipe n’est pas que de décou­per en petits lots plus faciles à esti­mer pour pouvoir reprendre une déci­sion entre les diffé­rents lots.

    Il y a aussi une philo­so­phie derrière, celle de l’ap­port de valeur.

    Seul le présent créé de la valeur. La stra­té­gie envi­sage le futur, les rétros­pec­tives tirent les leçons du passé. Si vous n’êtes ni dans un contexte de choix stra­té­gique ni en train de tirer des leçons en rétros­pec­tive, vous ne devez que vous préoc­cu­per de la meilleure façon d’ap­por­ter de la valeur là, main­te­nant, tout de suite, peu importe ce que vous aviez pu prévu ou estimé par le passé.

    Que dois-je faire aujourd’­hui et main­te­nant pour appor­ter le plus de valeur ?

    La perti­nence de l’es­ti­ma­tion passée ne m’est jamais d’au­cune utilité pour répondre à cette ques­tion. J’in­siste : Jamais. Je prends en compte les diffi­cul­tés et faci­li­tés dans des rétros­pec­tives pour m’amé­lio­rer. Je les prends en compte pour évaluer l’ef­fort à four­nir sur le reste à faire, et donc l’op­por­tu­nité de conti­nuer. Que ces faci­li­tés ou diffi­cul­tés aient été prévues ou non, que j’ai divisé par 2 ou multi­plié par 20 mon esti­ma­tion n’im­porte fina­le­ment aucu­ne­ment.

    Esti­mez, c’est utile, impor­tant. Ensuite oubliez-les et surtout ne les réuti­li­sez pas pour autre chose.

    (sur le même sujet We don’t need no stin­king esti­mates)

    Photo d’en­tête sous licence CC BY-NC-SA par Mark Notari

  • S’oc­cu­per de l’ave­nir et pas du passé

    Pour faci­li­ter les esti­ma­tions l’état de l’art est de travailler par compa­rai­son. On prend la tâche la plus simi­laire réali­sée par le passé et on estime si la nouvelle va rele­ver du même effort, un peu plus ou un peu moins, en fonc­tion des diffi­cul­tés atten­dues.

    Les esti­ma­tions s’amé­liorent vrai­sem­bla­ble­ment avec l’ex­pé­rience, tant parce qu’on a plus de chances d’avoir une réfé­rence simi­laire, que parce qu’on a déjà traversé beau­coup de problé­ma­tiques et qu’on risque moins d’en oublier une.

    Pour que cela fonc­tionne au mieux il faut savoir reve­nir sur ce qui a été réalisé : Iden­ti­fier les diffi­cul­tés, les faci­li­tés, les impré­vus passés. Cher­cher comment on pourra les résoudre mieux ou les iden­ti­fier plus tôt.

    Le dernier verbe conju­gué est au futur.

    Je cherche comment on pourra résoudre les diffi­cul­tés ou impré­vus, pas comment on aurait pu les résoudre. La diffé­rence est de taille. Le passé ne m’in­té­resse pas en soi, c’est trop tard. C’est le futur qui m’in­té­resse.

    Ça peut semble une ques­tion de voca­bu­laire mais ça ne l’est pas. Parfois la réponse est la même, mais pas toujours :

    Imagi­nons qu’une tâche a tota­le­ment dérapé à cause d’une problé­ma­tique majeure qui n’avait pas été prévue. Pour finir la tâche on a du résoudre la problé­ma­tique, elle ne bloquera donc plus jamais. Une démarche qui aurait pu permettre d’iden­ti­fier ce problème en amont ne m’in­té­resse pas, vu que juste­ment ce problème n’exis­tera plus à l’ave­nir. Je suis poten­tiel­le­ment inté­ressé par une démarche qui permet­trait d’iden­ti­fier les autres futurs problèmes qui ne ressemblent pas à celui passé et qui nous sont incon­nus aujourd’­hui. Si on trouve cette perle rare trouve alors on l’adopte, mais sinon on s’épargne du temps et on passe à autre chose.

    Une prévi­sion passée n’est qu’une vision d’un autre présent, peu utile pour prépa­rer l’ave­nir

    Dans la boucle d’ap­pren­tis­sage, je m’in­té­resse au temps passé, aux diffi­cul­tés rencon­trées, aux faci­li­tés que je pour­rais avoir, et aux impré­vus qui sont surve­nus. Je m’y inté­resse car ils sont sources d’amé­lio­ra­tion, que l’es­ti­ma­tion de la tâche passée ait été juste ou ait été fausse.

    En fait savoir quelle était l’es­ti­ma­tion passée et si elle a été respec­tée ne m’est d’au­cune utilité pour m’amé­lio­rer. Si j’ai eu un imprévu, alors que l’ana­ly­se­rai, même si fina­le­ment j’ai eu assez de temps pour le gérer. En fait je l’ana­ly­se­rai même surtout si j’ai eu assez de temps pour le gérer, parce que ça veut dire que j’ai eu une faci­lité par ailleurs qui mérite elle aussi d’être analy­sée.

    Inver­se­ment, si je n’ai eu aucune diffi­culté signi­fi­ca­tive, aucun imprévu ni aucune spéci­fi­cité remarquable, il est probable que je me serve du temps passé sur ma tâche comme réfé­rence pour la suivante simi­laire. Avais-je réussi ou échoué à mon esti­ma­tion la dernière fois ? Peu importe : Main­te­nant j’ai appris et je peux me servir d’un cas concret comme base de réfé­rence. L’es­ti­ma­tion passée n’entre pas en ligne de compte, et encore moins si elle était mauvaise.

    L’es­ti­ma­tion ne sert qu’à déci­der de l’ave­nir. Une fois qu’elle est passée, elle est aussi inté­res­sante qu’un bulle­tin d’ho­ro­scope de l’an­née dernière.

  • Une pure neutra­lité du Net est impos­sible et illu­soire

    Pour rendre compte de l’adop­tion par les États-Unis d’une neutra­lité des réseaux Inter­net, France 24 titre « Une pure neutra­lité du Net est impos­sible et illu­soire« .

    Allez compren­dre…

    Alors pourquoi ? J’avais parié sur parce-que-les-terro­ristes, mais ils visi­ble­ment l’ex­pert préfère les argu­ments éprou­vés. Il en est resté à parce-que-la-pédo­por­no­gra­phie.

    Pour Orange, ses données sont beau­coup plus rentables que celles de Skype. Il pour­rait donc déci­der de ralen­tir ou de bloquer les données de Skype pour que les gens utilisent ses services. La neutra­lité du Net prise dans sa forme la plus pure l’in­ter­dit. Évidem­ment, ce prin­cipe doit être nuancé. Il est parfois néces­saire de ralen­tir ou de bloquer certaines données comme par exemple la pédo­por­no­gra­phie.

    Faire en sorte que la pédo­por­no­gra­phie aille moins vite, c’est ça ? euh… je demande toujours à comprendre. D’au­tant que même quand on parle de blocage, je ne vois aucune rela­tion entre le refus de trans­mettre un contenu jugé illé­gal et la capa­cité de favo­ri­ser ses propres services pour raisons commer­ciales.

    Je dis ça je ne dis rien mais la pédo­por­no­gra­phie ici est surtout un joli prétexte qui n’a rien à voir avec le sujet.

    Jusqu’où doit-on fixer le curseur ? Une pure neutra­lité du Net est impos­sible et illu­soire. Il y a certains cas qui doivent être prévus. C’est toute une négo­cia­tion avec les opéra­teurs de télé­pho­nie.

    Bref, on répète le titre mais on s’abs­tient surtout de donner des exemples qui semblent légi­times. D’ailleurs s’il s’agis­sait de pédo­por­no­gra­phie on verrait mal pourquoi on négo­cie­rait pour cela avec les opéra­teurs de télé­pho­nie.

    Bref, d’autres pays l’ont fait, les États-Unis ne sont pas les seuls. Nous nos experts disent que c’est impos­sible et notre presse relaie sage­ment la contra­dic­tion avec la réalité. Bravo Fran­ce24

     

  • Bash­git prompt

    Je bave souvent devant les prompt de termi­nal qu’on voit sur le web mais une fois installé ça fait très gadget, plus gênant qu’autre chose.

    J’ai tout de même ajouté un peu de couleur, pour aider à repé­rer le début de chaque invite quand je remonte dans l’his­to­rique.

    gitprompt

    Reste que quelques indi­ca­teurs ça peut être utile dans un réper­toire git. J’ai tenté oh-my-git mais fina­le­ment je me suis fixé sur bash-git-prompt, avec quelques icônes simples à comprendre. Je regrette juste le nombre de couleurs trop élevé mais ça doit se confi­gu­rer.

  • États-Unis : victoire cruciale pour la neutra­lité du Net

    Les cinq commis­saires qui dirigent la FCC ont consi­déré par trois voix contre deux que l’In­ter­net améri­cain devait désor­mais être consi­déré comme un « bien public » au même titre que le réseau télé­pho­nique, ce qui donne à la Commis­sion le pouvoir de faire appliquer la neutra­lité d’In­ter­net sur le terri­toire améri­cain.

    […] La Commis­sion peut désor­mais inter­dire aux four­nis­seurs d’ac­cès à Inter­net de bloquer arbi­trai­re­ment des conte­nus légaux, de ralen­tir ou d’ac­cé­lé­rer les flux de données sans justi­fi­ca­tion ou de prio­ri­ser certains conte­nus tran­si­tant par leur réseau moyen­nant paie­ment.

    C’est encore plein de détail, le combat est loin d’être fini, et n’a même qu’à peine commencé en Europe, mais c’est la bonne nouvelle de la semaine. Très impor­tante pour l’ave­nir.

  • Trois choses sur lesquelles vous devriez copier Google

    • Takeout : Pouvoir télé­char­ger toutes vos données dans un format stan­dard via un gros fichier zip.
    • Vali­da­tion en deux étapes : La possi­bi­lité d’im­po­ser un aller-retour par SMS ou l’uti­li­sa­tion d’une appli­ca­tion smart­phone en plus du mot de passe, pour sécu­ri­ser correc­te­ment votre compte.
    • Gestion­naire de compte inac­tif : Un système pour donner accès à vos données à une personne dési­gnée à l’avance si jamais votre compte devient inac­tif trop long­temps (avec une alerte pour vous permettre d’an­nu­ler l’opé­ra­tion juste avant qu’elle inter­vienne).

    Parce que pouvoir critiquer ce qui ne va pas implique aussi de pouvoir montrer ce qui est bien fait.

  • Infor­ma­tions person­nelles pour les sites e-commerce

    J’ai­me­rai tant un site e-commerce qui ne me deman­de­rait pas de créer un compte pour faire un achat. Qu’il me soit obli­ga­toire de décli­ner nom et adresse pour par exemple ache­ter un livre en ligne… est plus que gênant

    Je regarde la super lampe déco, je clique sur « ache­ter », je saisis une éven­tuel­le­ment adresse de livrai­son, puis mon numéro de carte bancaire, je valide, et voilà !

    Je n’ai pas besoin de plus pour ache­ter mon pain à la boulan­ge­rie, un lit ou une armoire dans mon maga­sin de meuble, ou un livre à ma librai­rie. Tout ce qui vient en plus avant la fina­li­sa­tion de la commande me fera fuir.

    Parce qu’il y a parfois un besoin d’une rela­tion après vente, je peux comprendre qu’on me demande aussi un numéro de télé­phone ou un email, même si ce n’est pas stric­te­ment néces­saire. On pourra m’y envoyer un jeton d’ac­cès pour me relier à mes commandes ou m’au­then­ti­fier si besoin.

    Je ne vois aucune raison incon­tour­nable d’im­po­ser la saisie de plus d’in­for­ma­tions [en fait si, voir commen­taires]. Je n’ai ni besoin d’un compte ou d’un mot de passe, ni besoin de décli­ner mon iden­tité.

    Rien n’em­pêche de propo­ser la saisie de bien plus d’in­for­ma­tions, mais après la commande, et de façon tota­le­ment option­nelle.

  • Pagi­na­tion sans limit ni offset

    TL;DR: La pagi­na­tion c’est bien™, le faire avec des para­mètres limit/offset c’est mal™.

    C’est très simple à expliquer : Si les données sont mises à jour entre deux requêtes d’une même pagi­na­tion, au mieux vous manquez des données et en visua­li­sez d’autres en double, au pire vous corrom­pez tous vos calculs.

    Hyper­me­dia

    La solu­tion magique c’est que vos API retournent un nombre limité de résul­tats avec des liens dans les entêtes, proba­ble­ment un rel=next pour les données suivantes et/ou un rel=prev pour les données précé­dentes. Le client n’a qu’à suivre les liens.

    En pratique

    OK, je triche parce que je n’ex­plique rien, alors je vais prendre un exemple : Un hypo­thé­tique client Twit­ter sur une hypo­thé­tique API Twit­ter (je m’au­to­rise donc à ne pas préci­ser ce qui se fait sur les API actuelles).

    Lorsque Twit­ter vous retourne les 100 derniers tweets de votre time­line avec les iden­ti­fiants 3245 à 3566, il peut vous renvoyer deux liens dans les entêtes :

    • Un rel=last qui mène en fait vers l’exacte requête que vous avez faite mais avec en plus un para­mètre since_id=3566. Quand vous voudrez rafrai­chir votre time­line, il vous suffira de suivre le lien. Il vous retour­nera les nouveaux messages jusqu’au 3566 non compris, mais jamais ceux que vous avez déjà reçu.
    • Un rel=prev qui mène vers l’exacte même requête que vous avez faite, mais avec en plus un para­mètre max_id=3245. Quand vous voudrez aller cher­cher les messages plus anciens, il vous suffira de suivre le lien.

    Si vous suivez un rel=prev après avoir suivi un rel=last vous fini­rez avec un lien qui contient et un since_id et un max_id, vous assu­rant de combler les trous que vous avez dans votre time­line, sans jamais renvoyer un message en double ni en oublier.

    Si vous souhai­tez faire une synchro­ni­sa­tion complète, il suffit de stocker tous les liens rel=prev que vous rece­vez dans une liste, et d’al­ler les suivre un à un à la fréquence que vous souhai­tez. Vous pouvez avoir un autre fil d’exé­cu­tion en paral­lèle qui suit le rel=last de temps en temps (il n’y en aura qu’un seul à la fois, vous en aurez un nouveau à chaque fois que vous suivez le précé­dent).

    Bon, dans la vraie vie vous aurez géné­ra­le­ment un rel=next (messages juste suivants) plutôt qu’un rel=last (derniers messages), mais Twit­ter est parti­cu­liers : Ça va si vite qu’en géné­ral la prio­rité est d’avoir les derniers messages à date, quitte à géné­rer des trous dans la time­line qui seront comblés plus tard.

    Twit­ter est aussi facile parce qu’on trie toujours pas date, et que l’iden­ti­fiant unique de chaque message est toujours ordonné lui aussi. Ailleurs on utili­sera peut être la date de dernière modi­fi­ca­tion comme pivot pour gérer la pagi­na­tion. L’im­por­tant est que le critère de tri soit cohé­rent avec la donnée utili­sée comme pivot

     

  • Front-end desi­gner ou inté­gra­teur web ?

    On m’a toujours séparé la notion de graphiste web en deux : D’un côté la créa­tion, l’illus­tra­tion. De l’autre le maquet­tage, l’agen­ce­ment, l’er­go­no­mie et les inter­faces.

    Côté déve­lop­peur web il y a les back-end pour le code métier et le code serveur, ainsi que les front-end pour le code inter­face.

    Inté­gra­teur

    Faire du pur HTML/CSS, c’est parfois pris par des déve­lop­peurs front-end, parfois par des graphistes d’in­ter­face. C’est typique­ment ce qu’est l’inté­gra­teur web. Le métier a pris une forte spécia­li­sa­tion depuis 10 ans. Il faut bosser dans un envi­ron­ne­ment très hété­ro­gène, avoir des notions d’er­go­no­mie, beau­coup de connais­sances sur les navi­ga­teurs, y compris tech­nique, faire face à des tech­no­lo­gies en pleine évolu­tion, consi­dé­rer les perfor­mances, etc.

    Je lis les tenta­tives de nommage de desi­gner front-end suite aux inter­ro­ga­tions de STPo. J’avoue avoir un peu de mal parce que ce que j’en lis ressemble quasi­ment parfai­te­ment à ce que j’au­rais nommé inté­gra­teur.

    Has-been ?

    Si je devais envoyer une pique, j’ai l’im­pres­sion qu’il y a un petit complexe face aux nouveaux front-end deve­lo­per, c’est à dire ceux qui font de l’ap­pli­ca­tif JS avec une compé­tence HTML/CSS/HTTP (et déjà, vous notez qu’on manque d’un terme vu que le déve­lop­peur PHP on l’ap­pe­lait déjà front-end deve­lo­per dans pas mal de boites, par oppo­si­tion à celui qui gère le code métier dans des serveurs dans inter­face client).

    Oui il y a une demande de ces nouveaux front-end deve­lo­per, et ça fait perdre un peu de contrats aux inté­gra­teurs qui ne couvrent pas cet aspect. Mais si vous accep­tez de délais­ser ce terme en le quali­fiant de has-been, c’est vous-même qui reti­rez de la valeur au métier. Il faudrait le renfor­cer, commu­niquer dessus, montrer la valeur… D’au­tant que trop de front-end deve­lo­per sont juste­ment du coup plus faibles en inté­gra­tion, à connaitre le support de tous les navi­ga­teurs, les bugs louches de CSS, la compa­ti­bi­lité qui ne se résume pas à la dernière version de Chrome, etc.

    N’ou­bliez pas que c’est comme ça qu’on a créé ce terme dans le web il y a moins de 10 ans. Avant il y avait les webmas­ter d’un côté, et les déve­lop­peurs de l’autre. Le terme d’in­té­gra­teur on l’a juste­ment à l’époque imposé comme l’ex­pert qui savait faire ce code HTML/CSS avec un peu de javas­cript si besoin, et soit une tendance graphiste soit une tendance avec un peu de PHP, souvent les deux.

    Tenter un nouveau terme juste pour rajeu­nir l’image, c’est pour moi une vision non seule­ment très court terme, mais aussi défen­sive en aban­don­nant la valeur au lieu de la renfor­cer à valo­ri­ser le métier.

    Desi­gner

    Reste la ques­tion de l’an­glais, où le terme d’in­té­gra­teur web ne semble pas exis­ter. Propo­ser un terme autre que front-end deve­lo­per peut avoir du sens, mais je ne suis pas convaincu qu’il faille cher­cher dans une spécia­li­sa­tion de desi­gner.

    Je sais que les gens qui parti­cipent à la discus­sion en lien sont quasi­ment tous graphistes *et* inté­gra­teurs. Pour autant, quitte à parler spécia­li­sa­tion des métiers et valo­ri­sa­tion de celui d’in­té­gra­teur, j’au­rais aimé un terme qui regroupe tous les inté­gra­teurs plutôt que de mettre ceux qui débordent côté graphisme dans la case maitresse desi­gner et ceux qui débordent côté program­ma­tion dans la case maitresse deve­lo­per.

    C’est oublier ceux qui sont au milieu et croire que fina­le­ment le métier inter­mé­diaire n’existe pas en soi. Bref, aller là aussi à l’en­contre de la valo­ri­sa­tion du métier spéci­fique d’in­té­gra­teur, en le relé­guant comme une cartouche secon­daire d’un graphiste ou d’un déve­lop­peur.

    S’il est sain de créer des termes pour des spécia­li­sa­tions, ne créons pas des termes pour décrire ceux qui sont à la fois sur deux ou trois spécia­li­sa­tions précises, sinon on ne s’en sortira jamais et on ne fera que divi­ser. Si vous couvrez plusieurs cases – ce qui est non seule­ment très bien mais carré­ment souhaité – dites simple­ment que vous êtes inté­gra­teur et graphiste d’in­ter­faces, ou inté­gra­teur et déve­lop­peur front, ou encore autre chose. Cumu­lez, ne divi­sez pas.

    front-end

    Indé­pen­dam­ment de tout ça, même si on veut clas­ser les inté­gra­teur dans les desi­gner (qui en anglais ne recoupe pas que la notion de graphisme au sens français, je le conçois), je ne comprends pas le quali­fi­ca­tif de front-end ici. Pour le déve­lop­pe­ment il y a du back et du front, mais sauf erreur de ma part le desi­gner s’oc­cupe toujours du front – et ce qu’il fasse de l’in­té­gra­tion tech­nique, de la concep­tion d’in­ter­face ou de l’illus­tra­tion/créa­tion.

    Inter­face desi­gner m’au­rait déjà moins choqué mais je crois que c’est déjà occupé par un poste moins tech­nique. Je n’ai pas mieux à propo­ser mais front-end desi­gner ne me semble rien vouloir dire.

    Je m’amuse de voir que pour une fois, nous avons foison de termes spécia­li­sés en français alors que les anglais n’ont qu’une poignée de termes très géné­riques.

    Et moi ?

    J’ai toujours eu du mal à me mettre dans une seule case, et j’es­père qu’il en va de même pour beau­coup de gens dans le web. Même quand je ne faisais que de la tech­nique, je n’ai jamais su si j’étais déve­lop­peur ou inté­gra­teur.

    J’étais les deux. Certai­ne­ment pas « simple­ment front-end deve­lo­per » dans le sens « inté­gra­teur qui déve­loppe », parce que j’ai toujours vu inté­gra­teur comme une casquette à part entière, qui demande une exper­tise gigan­tesque qui éclipse large­ment le côté « qui déve­loppe ».

    Bref, je ne me retrouve certai­ne­ment pas dans cette sépa­ra­tion des graphistes d’un côté et des déve­lop­peurs de l’autre, en éclip­sant les inté­gra­teurs au milieu. Très dommage.

  • Google Drops Support for Secu­rity Ques­tions

    Google Drops Support for Secu­rity Ques­tions

    …et fran­che­ment il était temps. Ces systèmes de ques­tions person­nelles sont tota­le­ment aber­rants. Bref, merci.

    Il s’agit géné­ra­le­ment de ques­tions dont on peut trou­ver la réponse avec un mini­mum de recherches sur le net. Les amis et les proches connaissent déjà toutes les réponses ou peuvent les obte­nir rela­ti­ve­ment faci­le­ment à force de discus­sion.

    À l’in­verse, mon profes­seur préféré ? La rue de là où j’ai habité petit ? J’au­rais plusieurs réponses possibles. J’hé­site à chaque fois. Il est même possible que certains de mes proches répondent plus rapi­de­ment que moi-même à ces ques­tions – tout en donnant la bonne réponse.

    Un ou plusieurs numé­ros de télé­phone, un ou plusieurs emails, une liste de codes de secours à usage unique… Google fait très bien tout ça. L’avan­tage de ces solu­tions c’est que même si quelqu’un usurpe le compte, le service client peut les réuti­li­ser pour authen­ti­fier le vrai proprié­taire des données.

    Tout au plus on pour­rait imagi­ner de deman­der au service de confir­mer cumu­la­ti­ve­ment par plusieurs moyens, du genre mon télé­phone de bureau, plus le numéro person­nel de mes parents, plus l’email de ma femme. Peu probable que quelqu’un réus­sisse à avoir accès aux trois simul­ta­né­ment sans que je n’en ai connais­sance. Si je perds vrai­ment tous mes accès, cette diffi­cul­tés sera surmon­table.

    Visi­ble­ment des gens se permettent de remettre en ques­tion les pratiques dont le coût est supé­rieur au béné­fice : Je vois des banques désor­mais sans ces claviers virtuels inutiles et je me rappelle Mozilla qui avait arrêté de deman­der le renou­vel­le­ment régu­lier des mots de passe.

    Bon, tout n’est pas gagné partout : Linke­din ne véri­fie pas les emails des nouveaux comptes, et ça ouvre de jolies failles chez tous ceux qui ont un « authen­ti­fie-moi avec Linke­din ».

    Photo d’en­tête sous licence CC BY par Zuerichs Stras­sen