Catégorie : Technique

  • 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

  • Working with desi­gners

    Working with desi­gners

    J’ai lu récem­ment le Working with desi­gners, et ça me donne l’oc­ca­sion de publier une réflexion qui me trotte dans la tête depuis long­temps :

    Vous avez besoin d’un graphiste dans votre équipe.
    En interne, à demeure.

    Oui, on peut très bien faire un peu tout sans graphisme, et trou­ver un pres­ta­taire quand il s’agit quelques fois dans l’an­née de faire une charte, un design ou une illus­tra­tion. Vous manquez juste 80% de la valeur ajou­tée.

    En fait c’est plus large que ça. On peut tech­nique­ment avoir juste un CEO, qui achète des pres­ta­tions de déve­lop­pe­ment infor­ma­tique à une SSII, délègue le cahier des charges à un cabi­net d’as­sis­tance MOA, fait distri­buer la solu­tion par des vendeurs multi­cartes.

    Ça peut même fonc­tion­ner, dans de rares cas. Vous manquez juste la valeur qui est de réflé­chir au produit, de faire des évolu­tions perma­nentes et progres­sives, de lais­ser les gens s’ex­pri­mer, colla­bo­rer, avoir des initia­tives, appor­ter de la valeur, de l’ému­la­tion… On ne parle pas que de produc­tion sur le projet, mais de parti­ci­per et enri­chir la vie de l’en­tre­prise à tous les niveaux.

    * * *

    En régime de croi­sière, pour une boite techno web, vous aurez besoin d’un déve­lop­peur back, d’un déve­lop­peur front, d’un expert produit/métier, d’un graphiste, d’un commer­cial/marke­ting, d’une personne pour le support client, et d’une personne pour gérer l’ad­mi­nis­tra­tif.

    On peut bien entendu parler aussi d’un direc­teur des opéra­tions ou d’un sys admin, mais ils ne font pas autant parti du même coeur mini­mum pour moi.

    Chacune de ces sept personnes vous appor­tera quelque chose dans l’en­tre­prise,mettra de l’huile dans les rouages, même en dehors du projet lui-même.

    *

    Au départ il n’y a pas le choix, il faut porter plusieurs casquettes et faire quelques impasses. Par la suite vous avez tout inté­rêt à ce que les rôles soient poreux, que chacun soit incité à travaillé sur plus que sa petite case.

    Si par contre vous êtes une dizaine et que vous n’avez pas une personne diffé­rente qui joue le guide pour chacun des rôles, vous ne faites pas une écono­mie, vous vous ampu­tez d’une grosse valeur ajou­tée.

    *

    Votre boite n’est pas une boite techno web ? Dans ce cas vous pouvez peut être éviter d’avoir deux déve­lop­peurs distincts, mais il faudra au mini­mum les rempla­cer par un bidouilleur infor­ma­tique à tout faire (au sens noble, si vous croi­sez le terme anglais hacker, c’est de ça qu’on parle), qui devien­dra vite indis­pen­sable.

    Dans ce cadre, j’aime beau­coup la notion « hacker in resi­dence » et « desi­gner in resi­dence » de eFoun­ders. C’est la compré­hen­sion que même parta­gés entre plusieurs projets, pour faire émer­ger de la valeur il faut des gens impliqués à demeure, au milieu des équipes.

    Photo d’en­tête sous licence CC BY-SA par Axel Hart­mann