Catégorie : Technique

  • TLS et vie privée

    Pour répondre à David :

    TLS does not provide privacy. What it does is disable anony­mous access to ensure autho­rity. It changes access patterns away from decen­tra­li­zed caching to more centra­li­zed autho­rity control.
    That is the oppo­site of privacy. […] TLS is NOT desi­rable for access to
    public infor­ma­tion, except in that it provides an ephe­me­ral form of message inte­grity that is a weak repla­ce­ment for content inte­grity.

    Je suis convaincu que ces gens ont réflé­chi à la ques­tion plus long­temps et plus sérieu­se­ment que moi, mais je ne peux m’em­pê­cher de poser les ques­tions :

    Parler de vie privée c’est parler de confi­den­tia­lité. Vis à vis de qui ? De même, à partir de quand parle-t-on d’ano­ny­mat ?

    Consi­dé­rer que TLS est inutile pour accé­der à une infor­ma­tion publique me semble très étrange. La confi­den­tia­lité n’est pas dans le fait que cette infor­ma­tion soit publique, mais à ce que je consulte ou ce que j’en­voie dans le détail.

    Savoir que j’ac­cède à Face­book est une chose. Savoir quel profil j’uti­lise et ce que j’écris en est une autre, quand bien même les textes en ques­tions sont ne sont pas d’ac­cès restreint. Je ne souhaite pas forcé­ment que l’uni­ver­sité de mon fils puisse lire ce qu’il y écrit via le WIFI local.

    Savoir que j’ac­cède à Wiki­pe­dia est une chose. Savoir que les pages que j’y lis parlent de certains problèmes de sexua­lité en est une autre. Je ne souhaite pas forcé­ment que mon employeur puisse savoir ce que j’y lis pendant ma pause de midi.

    Savoir que je consulte la presse est une chose. Savoir quels sont les articles poli­tiques que je lis et ce que je commente en est une autre. Suivant le pays où je suis, je ne souhaite pas faci­li­ter une éven­tuelle analyse au niveau de mon four­nis­seur d’ac­cès ou du gouver­ne­ment.

    Bref, je suis conscient que l’im­plé­men­ta­tion actuelle des navi­ga­teurs peuvent en théo­rie faci­li­ter le tracking à partir du serveur. Je ne suis pas certain que la tech­nique soit mise en œuvre telle­ment d’autres méthodes plus simples sont effi­caces. La confi­den­tia­lité que ça m’ap­porte compense large­ment ce surcoût.

    La démo­cra­ti­sa­tion de TLS est pour moi une vraie bonne nouvelle.

    I have no objec­tion to the IESG propo­sal to provide infor­ma­tion *also* via https. It would be better to provide content signa­tures and encou­rage mirro­ring

    Je ne nie pas que ça puisse être inté­res­sant, mais l’usage est pour moi tota­le­ment diffé­rent. En fait, à réflé­chir, l’es­sen­tiel des cas où j’ai besoin de garan­tir l’in­té­grité du message sont ceux où j’ai besoin d’une authen­ti­fi­ca­tion, donc où le chif­fre­ment de TLS est aussi néces­saire.

    Propo­ser HTTPS en alter­na­tive me semble aussi une fausse bonne idée. Sur mes deux derniers exemples, j’ai poten­tiel­le­ment non seule­ment besoin que le contenu de ma requête soit confi­den­tielle, mais aussi que mon besoin de confi­den­tia­lité le soit aussi. Que j’uti­lise d’un coup TLS me fera paraitre « louche », ce que juste­ment j’au­rais souhaité éviter. Je l’ai d’ailleurs vu récem­ment dans la presse lors de mises en accu­sa­tion : le fait que les suspects aient utilisé des commu­ni­ca­tions cryp­tées faisait partie des éléments à charge, même sans savoir ce qu’ils ont échangé. Dange­reux, au mieux.

    Plus prag­ma­tique : Il serait facile de bloquer HTTPS pour la plupart des sites publics comme Wiki­pe­dia, Doctis­simo, Twit­ter ou Le Monde, obli­geant les gens à se rabattre sur HTTP. Même les geeks les plus au fait des problèmes ont tendance à accep­ter de dégra­der la commu­ni­ca­tion en clair quand le chif­fre­ment ne passe pas. Rendre TLS option­nel revien­drait à le reti­rer là où juste­ment il est le plus néces­saire.

    Le fait que le web avance pas à pas vers un « TLS unique­ment » est un gros pas en avant pour la confi­den­tia­lité vis à vis de mon envi­ron­ne­ment direct.

    TLS everyw­here is great for large compa­nies with a finan­cial stake in Inter­net centra­li­za­tion. It is even better for those provi­ding iden­tity services and TLS-outsour­cing via CDNs. It’s a shame that the IETF has been abused in this way to promote a campaign that will effec­ti­vely end anony­mous access, under the guise of promo­ting privacy.

    Bref, il y a des choses à faire. Par exemple s’as­su­rer de réduire l’iden­ti­fi­ca­tion possible du navi­ga­teur entre deux requêtes ? (le navi­ga­teur utilise-t-il le même certi­fi­cat à chaque fois ? si c’est ça le problème, il y a certai­ne­ment moyen de faire des rota­tions régu­lières, et de ne pas parta­ger un même certi­fi­cat entre diffé­rentes desti­na­tions).

    Quant à mon anony­mat, il est bien plus vidé de son sens à cause de mon IP qu’à cause du tracking : si j’ai vrai­ment besoin, je peux utili­ser un navi­ga­teur ou un profil diffé­rent pour certaines acti­vi­tés, mais mon IP demande un effort plus impor­tant pour être chan­gée.

    L’autre ques­tion est de savoir auprès de qui est-ce que je cherche le plus à être anonyme, et ce que repré­sente mon iden­tité. Google saura proba­ble­ment me relier à mon email. Mon FAI et mon employeur savent me relier à mon iden­tité civile

    Bref, travaillons à amélio­rer les problèmes de tracking. Ils ne me semblent cepen­dant pas inhé­rents à la tech­no­lo­gie TLS (me trompe-je ?). Ne jetons en tout cas pas le bébé avec l’eau du bain. Surtout si nous n’avons rien à la place.

    Roy T. Fiel­ding nous rappelle le prin­ci­pal danger de TLS et de « SSL partout » : la centra­li­sa­tion des auto­ri­tés de certi­fi­ca­tion. Et par exten­sion du Web.

    C’est un vrai problème, mais qui commence à être dépassé. Le nombre d’au­to­ri­tés de mon Fire­fox se rapproche des 200. Si on consi­dère que ces auto­ri­tés délèguent elles-mêmes à de multiples sous-auto­ri­tés, qui parfois font elles aussi de même, on est loin d’une centra­li­sa­tion déran­geante pour la vie privée. En fait il y a tant de délé­ga­tion que le prin­cipe même d’au­to­rité de confiance devient assez théo­rique.

    Il reste un problème de confiance (auto­rité) et un problème commer­cial. DANE et letsen­crypt sont deux initia­tives qui me font croire qu’on va lais­ser ça derrière nous à moyen (pour letsen­crypt) ou long terme (pour DANE).

    Un client qui sait ne pas réuti­li­ser inuti­le­ment le même certi­fi­cat, qui véri­fie le serveur à l’aide de DANE les écueils de confi­den­tia­lité suivants seront surtout dans SNI, DNS et IP.

  • Icon-font, hack ?

    Unicode intègre main­te­nant des picto­grammes depuis des années, et ça se renforce chaque version. Aujourd’­hui on doit dépas­ser les 1000 emoji, dont certains sont en réalité des modi­fi­ca­teurs. Avec la compo­si­tion ce sont des dizaines de milliers qui sont possibles. À cela il faut ajou­ter des milliers de symboles, de la flèche jusqu’à l’en­ve­loppe.

    Tout ça se retrouve ou se retrou­vera dans nos polices de carac­tères. C’est fait pour, à dessein.

    Dans Unicode, et donc dans nos polices de carac­tères se trouve aussi une plage de symboles dite « privée ». Elle est faite pour que vous y mettiez vos propres symboles, à vous, pour vos besoins. Tant qu’on reste là dedans, je ne vois pas trop pourquoi y ajou­ter un picto­gramme repré­sen­tant un panier d’achat serait plus ou moins un hack, une bidouille, que les emojis ou les symboles déjà présents.

    La seule diffé­rence est que vous êtes dans un espace privé donc que le sens de vos picto­gramme est inconnu des programmes qui les utili­se­ront. Bon, c’est prévu comme ça au départ aussi, à dessein, et c’est aussi vrai de n’im­porte quelle image sur une page web.

    Bref, les polices de carac­tères person­na­li­sées avec des picto­grammes, un hack ? ça se discute. Unique­ment si vous consi­dé­rez que les plages Unicode de symboles et autres emoji le sont aussi. Ça se discu­te…

  • Le métier de déve­lop­peur infor­ma­tique

    — Tim. (@TimDL1992) 16 Mai 2015

    Et cette blague est exac­te­ment pourquoi le travail d’un déve­lop­peur est complexe. Son rôle c’est de tout prévoir, tout en reti­rant tout contexte, toute inter­pré­ta­tion, tout intel­li­gence.

    La phrase la plus proche du métier selon moi c’est celle qui dit « L’in­gé­nieur en pont doit comprendre les enjeux du pont et en faire certains calculs, puis diri­ger des gens du métier pour qu’ils construisent ce pont. L’in­gé­nieur en infor­ma­tique doit non seule­ment savoir construire lui-même ce pont dans les moindres détails, depuis l’ex­trac­tion du mine­rai de fer jusqu’à la pose du revê­te­ment qui permet­tra de rouler dessus, parfois en passant par la construc­tion de l’ap­pa­reil qui extrait le mine­rai de fer lui-même, mais en plus il doit savoir expliquer cela pour le faire faire à des auto­mates qui exécu­te­ront pas à pas chaque instruc­tion avec moins d’in­tel­li­gence et moins d’ini­tia­tive person­nelle qu’un enfant de 3 ans avec un lourd retard mental« . C’est certes cari­ca­tu­ral (donc faux) mais ça donne l’idée.

  • Taxe sur la bande passante

    Et l’idée d’une taxe sur la bande passante revient sur le tapis. L’idée de base c’est de trou­ver un moyen de faire payer les grosses multi­na­tio­nales du web. Sauf qu’à mettre trop de choses sur le tapis, on finit par se prendre les pieds dedans.

    Donc on fait payer une taxe aux services qui consomment « beau­coup » de bande passante. Youtube, Spoti­fy… vous êtes dans le colli­ma­teur.

    Oups

    Ah, mais ça va concer­ner aussi Orange avec Deezer et Daily­mo­tion. Oups… Pour corri­ger ça on va faire un crédit d’im­pôt équi­valent. Si tu payes des impôts ici, en gros on te rembourse ta taxe, sinon tu en es pour ta poche.

    Géniale inven­tion… sauf que ça ne fonc­tionne pas. Même Google paye des impôts en France. Peu, proba­ble­ment pas assez, mais ils en payent. Quelques millions. Donc sauf si la taxe dépasse quelques millions, ça ne chan­gera rien. Si la taxe dépasse ce montant, il leur suffira de lais­ser un peu plus de reve­nus sur l’en­tité fiscale française pour que ça s’équi­libre et voilà. Croire qu’a­vec tout leur montage fiscal c’est ça qui va leur faire peur, c’est être plus que naïf.

    Oups (bis)…

    Ah, mais dans l’his­toire il n’y a pas que Youtube et Daily­mo­tion qui payent de la bande passante. Il y a aussi les content deli­very network et les héber­geurs. En gros tout ce qui est hébergé via un pres­ta­taire qui prend la bande passante à son nom. Eux seront « gros », mais vont refac­tu­rer ça à tous les petits ensuite, juste­ment ceux que personne ne souhaite faire payer pour ne pas frei­ner le numé­rique. Ça va des star­tups inter­net aux sites e-commerce en passant par les PME. Oups…

    Oups (ter)…

    Et puis tout ça c’est oublier que le four­nis­seur d’ac­cès (FAI) aussi il consomme de la bande passante, et pas qu’un peu. Tiens, on va taxer le four­nis­seur d’ac­cès aussi du coup ? Tous ceux qui font du P2P, qui envoient leurs photos de vacances sur un service en ligne, qui font du backup Crash­plan ou du partage Drop­box…

    Bref, ça va coûter et si la taxe sert vrai­ment à taxer, ça va être refac­turé aux abon­nés. Ou alors nos four­nis­seurs y trou­ve­ront une façon propo­ser leurs services internes au mépris de la concur­rence non faus­sée (Orange, je te regarde).

    Aie… j’ai mal à mon numé­rique

    Aujourd’­hui si le trafic est asymé­trique, c’est aussi en grosse partie la volonté des four­nis­seurs d’ac­cès qui imposent géné­ra­le­ment un ratio de 1/20 à 1/3 à leurs abon­nés. Vous croyez que ça va les inci­ter à ouvrir les vannes ou à les restreindre ? Dans ce modèle de taxe plus le trafic est asymé­trique, plus c’est à leur avan­tage.

    Par contre ça va pile dans la stra­té­gie des four­nis­seurs d’ac­cès qui veulent rari­fier arti­fi­ciel­le­ment la ressource réseau pour pouvoir la faire payer plus cher, renfor­cer leurs services payants internes et faire de la segmen­ta­tion dans leur offre (prio­rité de trafic, abon­ne­ment en fonc­tion de la bande passante dispo­nible, exten­sion de quota, etc.).

    En voilà autant pour le déve­lop­pe­ment du numé­rique en France.

    Tout ça parce que…

    Tout ça parce que nos FAI ne veulent pas faire face aux inves­tis­se­ments néces­saires à l’ex­plo­sion des usages et des conte­nus deman­dés par leurs propres abon­nés. Oui, on peut dire que les tarifs actuels ne couvrent pas les coûts. Ça n’a pas l’air de se véri­fier en réalité mais je laisse à d’autres le débat sur cette ques­tion. Si réel­le­ment nos FAI sous-facturent l’abonné, qu’ils fassent évoluer leur modèle de factu­ra­tion vis à vis de l’abonné au lieu de cher­cher des rentes à côté en main­te­nant un service à perte de l’autre.

    Tout ça aussi parce que nos FAI ont déjà conquis le marché (il n’y a plus énor­mé­ment de non-abon­nés Inter­net à conqué­rir) et qu’ils cherchent des solu­tions pour étendre leurs reve­nus. Ça passe par des options supplé­men­taires: Il y a l’op­tion de la segmen­ta­tion de trafic et des options réseau, qui demandent toutes deux de faire arti­fi­ciel­le­ment du réseau une ressource rare alors qu’elle est abon­dante aujourd’­hui. Il y a aussi le déve­lop­pe­ment de services internes concur­rents aux services dispo­nibles sur le web, et là il faut trou­ver un moyen de désa­van­ta­ger et rendre plus chers les concur­rents, d’où la taxe (entre autres).

    Tout ça aussi parce que notre État n’a pas le courage d’at­taquer de front le problème fiscal des géants du web et cherche 150 moyens détour­nés de les faire payer, quitte à ce que ça arrive dans les caisses d’in­té­rêts privés (par exemple le fond Google pour la presse) plutôt qu’au trésor public. Ça sera toujours ça qui arri­vera dans l’éco­no­mie française.

    Donc on enchaîne les idées bancales et pas assez réflé­chies qui font plus de mal que de bien.

    Rien de neuf…

    S’il y en a un des deux…

    Le pire c’est bien ce qui ressort de ce dernier lien : Ne pas oublier que Youtube ne pousse aucun contenu vers le FAI. Youtube (et les autres) répondent aux demandes venant du réseau du FAI (qui ont l’abonné pour source).

    S’il y en a bien un des deux qui est respon­sable du trafic échangé c’est juste­ment le réseau du FAI (via l’abonné) et non le four­nis­seur de service. En réflé­chis­sant un peu, c’est le FAI qu’on devrait taxer au profit du four­nis­seur de service. C’est d’au­tant plus vrai que les acti­vi­tés d’édi­tion de contenu (que ce soit du Youtube ou de la presse) sont rare­ment rentable, contrai­re­ment à nos four­nis­seurs d’ac­cès Inter­net, et que ce sont elles qui apportent le plus de valeur ajou­tée à la société

    Je sais qu’une vidéo de chat ce n’est pas du grand cinéma d’au­teur, mais un tuyau de plas­tique ou un câble de cuivre sans rien dedans c’est encore moins sexy côté cultu­rel.

  • Des cher­cheurs piratent à distance un robot de chirur­gie

    Une équipe de cher­cheurs de l’uni­ver­sité de Washing­ton est parve­nue à pira­ter un robot de chirur­gie télé­com­mandé à distance en exploi­tant plusieurs failles de sécu­rité, notam­ment via la connexion Inter­net qui relie le prati­cien au robot. S’il faut évidem­ment renfor­cer la protec­tion du système, les solu­tions tech­niques exis­tantes ne sont pas forcé­ment compa­tibles avec les besoins de la chirur­gie robo­tique télé­opé­rée.

    — Futura Sciences

    Le problème c’est que ça ne surpren­dra aucun infor­ma­ti­cien. C’est même quasi­ment une certi­tude pour tous ceux là.

    Et ça me fait peur que le corps médi­cal puisse décou­vrir ça, ou que ce type de service ne soit pas sur des liai­sons spécia­li­sées, distinctes d’In­ter­net.

    À l’heure où les États-Unis créent des virus infor­ma­tiques pour impac­ter à distance le programme nucléaire de l’Iran, je n’ose penser à l’arme que ces robots hospi­ta­liers peuvent deve­nir.

  • Que faire de Gemfile.lock et compo­ser.lock

    L’objec­tif du Gemfile c’est de dire « le projet a besoin de la biblio­thèque X en version 4.5 mini­mum, et de la biblio­thèque Y en version 1.3 à 1.5 ». L’objec­tif du Gemfile.lock c’est de dire « ici on a X en 4.5.6 et Y en 1.3.8, c’est cet ensemble précis qui est testé et mis en produc­tion ».

    J’ai encore vu passer la ques­tion il y a quelques jours

    Le Gemfile.lock, c’est quoi la bonne pratique, je le pousse sur le git ?

    Et la réponse clas­sique « Oui, pour s’as­su­rer que la produc­tion soit en phase avec les versions que tu as testé », avec parfois quelqu’un qui ajoute « sauf pour les paquets gem / compo­ser, où là il ne faut pas le pous­ser dans le dépôt git ».

    Sauf qu’en fait c’est plus complexe, et ce n’est pas une problé­ma­tique tech­nique. C’est une ques­tion d’or­ga­ni­sa­tion :

    Qui fait la main­te­nance appli­ca­tive ? Qui suit les mises à jour de sécu­rité au jour le jour ? Qui est dispo­nible en astreinte en cas de besoin ? Avez-vous une procé­dure de test auto­ma­tisé suffi­sam­ment fiable ? Quelle est la poli­tique de numé­ro­ta­tion de vos dépen­dances ?

    Plus exac­te­ment, le Gemfile.lock et le compo­ser.lock doivent être maitri­sés par l’équipe qui gère la main­te­nance de sécu­rité.

    Équipe de déve­lop­pe­ment

    Ce peut être l’équipe de déve­lop­pe­ment. Dans ce cas c’est à elle de pous­ser le .lock sur son outil de version­ne­ment, de le mettre à jour et de déclen­cher un déploie­ment en cas de besoin.

    Atten­tion : Dire « je pousse les .lock dans le git », c’est dire, « personne d’autre que moi ne doit y toucher ». C’est parfois présomp­tueux, mais ça veut aussi dire être respon­sable de la mise à jour, y compris quand on n’en n’a pas envie.

    Ça veut dire surveiller en perma­nence le besoin de mettre à jour une des dépen­dances pour des raisons de sécu­rité. Ça veut dire une veille active sur le sujet, du temps dédié à ça, et des outils ou proces­sus bien défi­nis. Très peu d’équipes de dev ont ça.

    Est-ce le rôle de votre équipe de dev ? en a-t-elle les moyens ? le temps ? l’au­to­no­mie ?

    Équipe de produc­tion

    À l’in­verse ça peut être à l’équipe de produc­tion de gérer ces arte­facts. Dans ce cas c’est à cette dernière de pous­ser les .lock sur leur propre version­ne­ment, avec le reste des confi­gu­ra­tions. Eux ont des proces­sus établis pour faire les veilles de sécu­rité, des astreintes en cas de mise à jour en urgence, etc.

    En échange ça veut dire que les dépen­dances sont spéci­fiées très sérieu­se­ment et plus préci­sé­ment dans le Gemfile. Parfois dire « je veux la version 4.5.* » et pas unique­ment « je veux une version 4 ou supé­rieure ». Pous­ser le Gemfile.lock sur le git de l’équipe de déve­lop­pe­ment peut aussi être un indi­ca­teur que le Gemfile d’ori­gine est géré avec légè­reté au départ.

    L’équipe de produc­tion se basera sur ces défi­ni­tions précises, sur les notes de mises à jour des dépen­dances, puis mettra à jour le code et le Gemfile.lock en fonc­tion. Elle fera ensuite passer les tests auto­ma­ti­sés, peut être une équipe de QA. À la fin elle pren­dra – ou non – la respon­sa­bi­lité de déployer en produc­tion la mise à jour sans passer par l’équipe de déve­lop­pe­ment, en fonc­tion de l’ur­gence et du risque. Ça impose donc aussi des tests auto­ma­ti­sés suffi­sam­ment solides pour se baser dessus lors d’une mise à jour mineure.

    Dans une grosse struc­ture, ou avec une équipe de produc­tion dédiée de qualité, c’est proba­ble­ment une des meilleures options. Mais… votre équipe de produc­tion est-elle compé­tente sur ces sujets ? a-t-elle l’au­to­no­mie suffi­sante pour cela ? le code, le Gemfile et les tests auto­ma­ti­sés sont-ils suffi­sa­ment à niveau ?

  • Les FAI devront livrer à l’Etat toutes les infos sur leurs réseaux

    Dans le cadre de ce contrôle, qui pourra avoir lieu une fois par an (ou plus souvent en cas de défaillances), les FAI et héber­geurs concer­nés devront four­nir à l’ANSSI ou au pres­ta­taire privé agréé « notam­ment la docu­men­ta­tion tech­nique des équi­pe­ments et des logi­ciels utili­sés dans ses systèmes ainsi que les codes sources de ces logi­ciels« 

    En clair : En plus des boites noires et des accès directs, il est demandé tous les moyens pour que l’État puisse s’in­tro­duire de force dans les systèmes, en dehors des accès prévus pour ça. Sous couvert d’en véri­fier la sécu­rité, mais même la marmotte ne croit plus à l’em­bal­lage arti­sa­nal du choco­lat dans le papier d’alu. Ayez confian­ce…

    — via Nume­rama

  • HTTP2 for front-end web deve­lo­pers

    To get websites to load in an accep­table time using HTTP1 we have deve­lo­ped a series of tech­niques; hacks really; to eke perfor­mance out of this old proto­col. They are:

    • Spri­ting: taking multiple images, combi­ning them into one image, and using CSS to only show part of that image in a parti­cu­lar place.
    • Conca­te­na­ting: Taking multiple CSS or JS files and sticking them into one large file.
    • Serving assets from a cookie-less domain.
    • Shar­ding: crea­ting different domains or sub-domains to host assets like images.

    Avec l’ar­ri­vée de HTTP 2, ces quatre opti­mi­sa­tions tendent à deve­nir inutiles, voire contre produc­tives.

    Pour les deux premières, le pipe­li­ning devient plus intel­li­gent (donc réel­le­ment utili­sable) et au besoin le serveur peut pous­ser les conte­nus sans même attendre qu’ils soient deman­dés par le client.

    Pour les deux suivantes, le système de compres­sion des entêtes et de multi­plexage rend le retour sur inves­tis­se­ment d’une nouvelle connexion TCP à un domaine tiers fran­che­ment contes­table. Vous risquez de perdre de la perfor­mance au lieu d’en gagner.

    La leçon est inté­res­sante. Pendant quelques années les déve­lop­peurs ont cher­ché à contour­ner les navi­ga­teurs, croyant pouvoir être plus smart. Le problème c’est que les navi­ga­teurs et les proto­coles ont évolué entre temps pour résoudre les mêmes problèmes. Les bouts de scotch des déve­lop­peurs peuvent désor­mais faire plus de mal que de bien. C’est toute une litté­ra­ture qu’il va falloir mettre à jour.

  • AT&T To Match Google Fiber In Kansas City, Charge More If You Want Privacy

    The company plans to charge $70/month for giga­bit service, but that’s a subsi­di­zed price. Subsi­di­zed by what, you ask? Your privacy. AT&T says if you want to opt out of letting them track your brow­sing history, you’ll have to pay $29 more per month. They say your infor­ma­tion is used to serve targe­ted adver­ti­sing, and includes any links you follow and search terms you enter.

    L’in­for­ma­tion n’est pas surpre­nante par son contenu mais par ses chiffres. Vos infor­ma­tions person­nelles valent 30€/mois d’après AT&T, unique­ment pour mieux cibler les publi­ci­tés (ça laisse donc entre­voir le gain des publi­ci­tés elles-mêmes, forcé­ment supé­rieur)

    — via Slash­dot

  • Et que fait-on des esti­ma­tions ?

    Quelle est votre stra­té­gie agile ?

    • Le plus stra­té­gique en premier ?
    • Ce qui est tech­nique­ment plus complexe en premier ?
    • Ce qui est le plus risqué en premier ?
    • Ce qui se voit en premier ?
    • Ce qui est le plus simple en premier ?
    • Ce qui apporte le meilleur retour sur inves­tis­se­ment en premier ?

    Il n’y a pas de bonne ou de mauvaise réponse. C’est unique­ment une histoire de stra­té­gie. L’im­por­tant est d’être cohé­rent sur une période pour mettre en œuvre cette stra­té­gie et de ne pas faire un peu de tout à la fois.

    Inté­res­sant de noter tout de même que sauf ordre de gran­deur extra­or­di­naire (donc facile à iden­ti­fier sans être bon en esti­ma­tion), seule les deux dernières stra­té­gies ont réel­le­ment besoin d’es­ti­ma­tion avant réali­sa­tion.