Catégorie : Vie professionnelle

  • Être comp­table de son temps

    Je vous conseille de commen­cer par la lecture du billet précé­dent, dont celui-ci est la suite : 2 à 3 heures par jour

    En voyant les ingé­nieurs de SSII remplir des fiches de temps heure par heure, je ne peux m’em­pê­cher de me dire que nous sommes au mieux dans une hypo­cri­sie parta­gée, plus proba­ble­ment dans une simple démarche perdant-perdant.

    Être comp­table

    En société de services infor­ma­tiques on découpe géné­ra­le­ment les projets en tâches, chacune esti­mée en heures. Les heures sont addi­tion­nées naïve­ment et huit tâches d’une heure tiennent tout à fait dans la jour­née d’un déve­lop­peur qui travaille 40 heures par semaine.

    Le déve­lop­peur a pour obli­ga­tion de « saisir ses temps », c’est à dire de saisir heure par heure sur quelle tâche il travaille. Je n’ai jamais vu ces impu­ta­tions utili­sées pour surveiller le travail ou faire du flicage mais la pres­sion néga­tive reste forte : Le déve­lop­peur doit affec­ter chaque heure de travail à une tâche. Une tâche qui a reçu suffi­sam­ment d’heures de travail doit logique­ment être termi­née et livrée.

    L’équa­tion malsaine heure de travail = heure passée sur une tâche produc­tive devient vite inso­luble pour ceux qui sont dans la même situa­tion que moi. On finit toujours par s’ar­ran­ger, souvent en rendant les impu­ta­tions en retard mais ça occupe un temps consé­quent pour soi et pour le chef de projet qui relance. Ça agace, énerve et épuise tout le monde, et occupe l’es­prit à faire des jeux comp­tables admi­nis­tra­tifs tout en donnant un senti­ment flot­tant de culpa­bi­lité ou de triche­rie.

    Certains comptent en dixièmes de jour­née mais c’est presque pire : Comme le chef de projet sait comp­ter, une tâche de 2h est codée 0,25 et on en a quatre dans la jour­née.  La diffé­rence c’est qu’il est beau­coup plus diffi­cile de consi­dé­rer avoir passé les heures qu’il faut et rentrer chez soi en se disant « tant pis, ça pren­dra plus de temps » (ça fonc­tionne dans un seul sens, si le déve­lop­peur termine plus tôt, il n’a pas le droit de partir pour autant, il commence la tâche suivante). Le seul gain c’est d’ajou­ter un peu plus de pres­sion sur le déve­lop­peur.

    Attentes réalistes, meilleurs résul­tats

    J’ai vu les choses tout autre­ment après avoir travaillé à Yahoo! On s’af­fec­tait l’équi­valent de 4 heures de travail par jour unique­ment, et personne n’était gêné que d’en­tendre « je n’ai rien fait ou presque ces deux derniers jours, je n’ai pas été produc­tif » au point de synchro du matin tant que le travail était collec­ti­ve­ment fait à la fin du mois.

    On peut faci­le­ment imagi­ner que ce serait la porte ouverte à des produc­ti­vi­tés mensuelles lilli­pu­tiennes voire à des abus, mais ça a proba­ble­ment été la période la plus produc­tive de ma vie de déve­lop­peur.

    La vérité c’est simple­ment qu’en atten­dant huit heures de travail par jour, mes autres employeurs ont en réalité dimi­nué ma produc­ti­vité mensuelle. J’ai passé une dose signi­fi­ca­tive de mon éner­gie dans les autres entre­prises à être comp­table et à lutter contre le système.

    À la décharge de mes employeurs, j’ai pour­tant toujours été dans des situa­tions avan­ta­geuses avec des tâches fourre-tout et des posi­tions de force qui m’ont permis d’être peu soumis au même régime que les autres. Je n’ose penser la galère que c’est pour celui qui a un poste de déve­lop­peur plus clas­sique.

    Tenter le 4 heures par jour

    L’idée qu’un déve­lop­peur peut faire huit ou même sept tâches d’une heure dans une jour­née de huit heures est tota­le­ment irréa­liste. Dans la réalité ce sont la qualité ou l’épui­se­ment des colla­bo­ra­teurs qui servent de variable d’ajus­te­ment, parfois les deux.

    Si vous avez des déve­lop­peurs respon­sables et moti­vés, vous pouvez essayer de partir sur des impu­ta­tions tâche à tâche et heure à heure avec une réfé­rence expli­cite à quatre ou cinq heures produc­tives par jour. Pour lisser les périodes plus ou moins actives il faudra accep­ter de ne regar­der cette métrique qu’en agré­geant par semaine ou par quin­zaine. Second point d’at­ten­tion : il faut que toute la hiérar­chie accepte de jouer le jeu, sinon on court à la catas­trophe au premier écueil projet.

    Ou lâcher prise sur les impu­ta­tions

    Si la situa­tion est moins idéale que ça, si le mana­ge­ment risque de ne pas jouer le jeu jusqu’au bout, ou simple­ment si l’équipe ne pense pas fonc­tion­ner sur ce rythme d’un faible nombre d’heures produc­tives par jour, on peut imagi­ner un scéna­rio plus proche des habi­tudes :

    L’im­pu­ta­tion se fait au niveau du projet et pas au niveau de la tâche, avec par blocs d’une jour­née ou demie jour­née. Parfois une demie jour­née n’aura quasi­ment pas été produc­tive, parfois elle le sera excep­tion­nel­le­ment, mais on ne fera pas de diffé­rence : la préci­sion sera globa­le­ment suffi­sante pour le repor­ting comp­table et admi­nis­tra­tif (le contrôle de gestion, la factu­ra­tion, l’éven­tuel crédits impôts-recherche).

    De l’autre côté l’avan­ce­ment projet est fait en mesu­rant … (atten­tion c’est révo­lu­tion­naire) l’avan­ce­ment du projet, et pas le temps travaillé. Ça semble enfon­cer les portes ouvertes mais c’est encore assez rare comme pratique.

    Quant au suivi des déve­lop­peurs eux même c’est un point RH chaque semaine. Ce qu’ap­porte un déve­lop­peur à une équipe ne pourra jamais être chif­fré en heures de travail ou en nombre de tâches affec­tées.

    Une dernière mise en garde

    En plus du rappel du billet précé­dent, je m’adresse à ceux qui veulent créer des équipes de déve­lop­peurs compé­tents, respon­sa­bi­li­sés et moti­vés. Si vous montez consciem­ment des équipes avec des ouvriers déve­lop­peurs qui font du travail à la chaîne, passez votre chemin.

    Enfin, chacun a son propre mode de fonc­tion­ne­ment. Je me contente de me baser sur le mien et sur ce que j’ai vu autour de moi. Je ne prétends pas que ça fonc­tion­nera pour quiconque d’autre. Par contre je suis convaincu de la néces­sité de jeter ou réfor­mer et le système d’im­pu­ta­tion des SSII et l’idée qu’on peut mettre pour huit heures de travail dans une jour­née.

  • 2 à 3 heures par jour

    Quand je déve­lop­pais, je pense que ma moyenne a le plus souvent tourné autour d’une douzaine d’heures de travail produc­tif par semaine. Par « travail produc­tif » j’en­tends « travailler à la tâche qu’on m’a demandé ». Cette moyenne était même assez irré­gu­lière pour que je me demande si une moyenne mensuelle ne serait pas plus adap­tée.

    À cette moyenne il faut toute­fois ajou­ter quelques périodes de surac­ti­vité dans l’an­née. Là je faisais peut-être huit à dix heures quasi conti­nues par jour, mais pas forcé­ment quand le projet en avait le plus besoin.

    Le reste du temps je papillon­nais, pour partie sur des acti­vi­tés tech­niques mais non néces­saires à la réali­sa­tion de mon travail, et pour partie sur des acti­vi­tés tech­niques, person­nelles, voire récréa­tives.

    Le non produc­tif essen­tiel à la produc­tion

    Je ne consi­dère pas ce temps passé « à ne rien faire » comme du temps perdu. Il m’était indis­pen­sable : Un travail intel­lec­tuel néces­site de pouvoir penser à autre chose, d’avoir du recul, de lais­ser les idées et la vision mûrir dans la tête. Plus que la réflexion, il faut aussi avoir une vision large sur ce qu’on fait et de ce qui se fait hors de son projet, hors des méthodes de sa société, y compris sur d’autres logi­ciels ou sur d’autres tech­no­lo­gies. C’est ainsi qu’on peut résoudre les problèmes effi­ca­ce­ment.

    Les salons de discus­sion avec les trolls ou échanges inter­mi­nables entre déve­lop­peurs, les centaines (milliers ?) d’heures passer à lire les blogs tech­niques, les autres centaines à lire les docs ou expé­ri­men­ter des choses qui n’ont rien à voir avec mon travail en cours… Tout ça s’est révélé d’une valeur inépui­sable pour mon travail. J’irai même plus loin en pensant que c’est souvent ce qui a fait la valeur de mon travail par rapport aux autres.

    Ces heures ne sont pas « produc­tives », mais elles sont rentables, et pas qu’un peu. J’au­rais certes pu travailler six à sept heures par jour, mais j’au­rais été beau­coup plus lent sur ces six heures. La produc­tion aurait été un peu plus impor­tante mais la qualité aurait aussi été drama­tique­ment plus basse. Sur un travail intel­lec­tuel, la valeur produite n’est pas propor­tion­nelle au temps passé, tout simple­ment.

    Pour la suite, c’est juste le lien suivant : Être comp­table de son temps.

    Un rappel toute­fois : Tout ce qui précède est vrai pour des déve­lop­peurs auto­nomes, respon­sables et moti­vés. L’or­ga­ni­sa­tion du temps d’un consul­tant ou d’une direc­tion me paraît tota­le­ment diffé­rente (même si là aussi huit tâches d’une heure ne tien­dront jamais dans une jour­née de huit heures), de même pour des déve­lop­peurs qui ont besoin d’être pris par la main.

  • What’s Your Geek Number? My Points System To Rate Soft­ware Engi­neers (without a full tech­ni­cal inter­view)

    Recru­ter est diffi­cile. Les candi­dats que je reçois sont parfois surpris du fait que je fais passer peu de tests tech­niques. J’ai appris à m’en méfier et que la réponse à des ques­tions simples est beau­coup plus signi­fi­ca­tive. La curio­sité, la connais­sance de l’état de l’art, l’état d’es­prit, sont fina­le­ment beau­coup plus impor­tantes.

    Et derniè­re­ment je tombe sur « What’s Your Geek Number? My Points System To Rate Soft­ware Engi­neers (without a full tech­ni­cal inter­view) ». La première impres­sion est de dire que c’est quand même irréa­liste comme façon de faire, puis en regar­dant de plus près et en tentant de forma­li­ser mes critères subjec­tifs, je me rends compte qu’ils n’en sont pas si éloi­gnés que ça.

    J’ajoute d’autres choses sur l’état d’es­prit et l’in­té­gra­tion à l’équipe, mais fina­le­ment c’est peut être sur ce types de critères que je fais le premier filtre.

  • Release early, release often

    Si j’ai retenu quelques choses de ceux qui réus­sissent, c’est qu’il faut arri­ver à avan­cer dans l’ordre, un pas à la fois. Mieux : Il faut sortir les projets le plus tôt possible, ne surtout pas attendre qu’ils soient finis.

    On se confronte plus rapi­de­ment au monde réel, à ses contraintes, aux clients, aux four­nis­seurs. On peut aussi mieux adap­ter la suite en gérant les prio­ri­tés telles qu’elles doivent l’être et non telles qu’on se les était imagi­nées. Le plus souvent cela permet même d’aban­don­ner des idées pour en mettre d’autres à la place, avant qu’il ne soit trop tard.

    Sortir tôt c’est aussi accep­ter de faire des compro­mis avec ses attentes et ses souhaits : On livre un produit ou un service qui sera en deçà de la cible qu’on cherche à atteindre, en deçà des services déjà exis­tants sur plusieurs points, et même pourquoi pas en deçà de ce qu’on consi­dère comme le mini­mum essen­tiel. Le tout est de prendre conscience que ce n’est qu’une étape, qu’on commence tous au début, et de s’en­ga­ger à bouger rapi­de­ment et fréquem­ment vers les objec­tifs fixés.

    Ce fonc­tion­ne­ment est main­te­nant un lieu commun dans les star­tup techno, mais c’est encore frus­trant pour tout le monde et une source d’in­com­pré­hen­sion pour beau­coup de tiers.

    La diffi­culté tient à commu­niquer sur la cible, montrer ce qu’on souhaite faire, tout en ména­geant les attentes car les premières versions ne seront que des premières versions, et que tout ne vient pas immé­dia­te­ment.

    Là où les encou­ra­ge­ments et l’écho posi­tif des tiers devraient être un encou­ra­ge­ment et une source de moti­va­tion, l’at­tente ou les premières versions incom­plètes peuvent très vite se retour­ner en juge­ments néga­tifs et en stress pour le projet. L’équi­libre est diffi­cile à trou­ver, je n’y suis pas encore. Notre objec­tif et notre travail conti­nuent en atten­dant.

  • My Star­tup Failed, But It’s OK

    Quand on en sera à cet état d’es­prit en France, on verra enfin une dyna­mique d’en­tre­pre­neurs et d’in­no­va­tion. En atten­dant, ici, on ne regarde pas ce que vous avez essayé de faire, mais si vous avez parti­cipé à une entre­prise qui a réus­sit quelque chose de gros.

    Le rejet de l’échec est telle­ment impor­tant qu’en tant que consul­tant j’ai vu ce que j’ap­pelle la stra­té­gie du para­pluie à tous les étages. D’autres l’ap­pellent la stra­té­gie IBM, du nom de « si j’ap­pelle IBM j’ai peu de chances de respec­ter le budget ou les délais, mais on ne me repro­chera pas cet échec pour­tant prévi­sible : j’au­rai pris les meilleurs ».

    Ce n’est pas dit ainsi dans My Star­tup Failed, But It’s OK, mais ça revient à ça : C’est en essayant qu’on peut réus­sir, et un échec servira toujours d’ex­pé­rience pour la suite.

    Les anglo­phones disent « keep on failing, keep on trying », je préfère « si vous n’êtes pas prêts à échouer, vous n’êtes pas prêts à réus­sir ». Et le coro­laire : Les gens prêts à réus­sir sont ceux qui ont déjà échoué.

    Ceux qui n’ont qu’une seule expé­rience et qui n’ont que réussi, vous ne saurez jamais si c’est grâce à eux, au contexte, à la chance, et s’ils en ont réel­le­ment tiré de l’ex­pé­rience. Pire : Ils arri­ve­ront avec plein de certi­tudes. Embau­chez des gens qui ont fait quelque chose, mais des gens qui ont échoué.

  • TEA cherche un renfort de talent pour son équipe tech­nique

    Nous commençons la réali­sa­tion d’une appli­ca­tion web desti­née prin­ci­pa­le­ment – mais pas exclu­si­ve­ment – aux tablettes. Il s’agit d’une réelle appli­ca­tion métier complexe et inno­vante, pas simple­ment d’un site de commerce ou de présen­ta­tion.

    Nous croyons fonda­men­ta­le­ment aux tech­no­lo­gies web stan­dard et à l’ou­ver­ture qu’elles apportent. Colla­bo­rer à proto­coles et formats communs ouverts ou publier en open source fait d’ailleurs partie de notre ADN et de nos inten­tions. Au lieu de gérer des appli­ca­tions natives iOS, Chrome et Android, nous allons tout faire en web : javas­cript css et html.

    Le poste

    Pour complé­ter l’équipe en cours de consti­tu­tion nous cher­chons un déve­lop­peur qui sait aller au fond des choses, cher­cher, apprendre, réali­ser et parta­ger, avec une exigence sur lui-même et qui privi­lé­gie la qualité.

    Ce peut être – préfé­ra­ble­ment – un déve­lop­peur avec déjà une bonne expé­rience sur une appli­ca­tion web mobile full javas­cript, ou quelqu’un travaillant de manière pous­sée sur tout ce qui gravite autour du terme « HTML 5 » ou « javas­cript », par exemple avec des réali­sa­tions open source. Celui que nous recher­chons sera le réfé­rent tech­nique qui sait tout ou qui saura tout assez rapi­de­ment, et qui saura trou­ver ce qui manque.

    Ensemble, nous parle­rons déve­lop­pe­ment, puisque conce­voir une appli­ca­tion complexe inté­gra­le­ment en javas­cript ce n’est pas comme faire un carrou­sel en jquery ou jouer avec la dernière librai­rie à la mode. À côté de ça nous parle­rons aussi inno­va­tion, archi­tec­ture, perfor­mance, compa­ti­bi­lité, mobi­lité, rendu écran, ergo­no­mie, latence et débit limité et plein d’autres choses très geek.

    Il faudra par exemple batailler avec des API javas­cript toutes fraiches, regar­der les diffé­rences d’im­plé­men­ta­tion des caches appli­ca­tifs navi­ga­teur, fouiller s’il faut utili­ser indexedDB ou webSQL, et proba­ble­ment aller sur caniuse.com plusieurs fois par jour les premiers temps. Des connais­sances poin­tues et à jour sur HTTP et toute la pile des tech­no­lo­gies web seront bien entendu essen­tielles.

    L’en­vi­ron­ne­ment

    Vous rejoin­drez alors une petite équipe sympa avec des déve­lop­peurs moti­vés, à jour sur les nouveau­tés et inno­va­tions web, avec une soif d’ap­prendre et de parta­ger. L’équipe fonc­tionne en méthodes agiles, auto­nome et sans chef de projet sur la partie tech­nique, en colla­bo­ra­tion avec un respon­sable produit sur le bureau d’à côté pour la partie fonc­tion­nelle.

    Il s’agit d’in­ves­tir sur le long terme pour réali­ser une appli­ca­tion qui évoluera en perma­nence et qui sera au cœur de l’ac­ti­vité. Nous n’en­vi­sa­geons donc qu’une colla­bo­ra­tion sous la forme d’un CDI dans nos locaux de Lyon. Si vous n’ha­bi­tez pas déjà Lyon et si le projet vous tente, même si nous savons que ça ne se fait pas toujours en un claque­ment de doigts, nous vous inci­tons à envi­sa­ger de venir nous rejoindre ici. Outre une ville bien sympa il y a le soleil, les plus grands lacs de France juste à côté, la mer à distance raison­nable, et les montagnes toutes proches.

    La société elle-même travaille à un projet dans le domaine du livre élec­tro­nique, avec pour ambi­tion de fédé­rer les acteurs de la chaîne du livre autour d’une plate­forme de distri­bu­tion et de services d’e-book ouverte, à l’échelle natio­nale et inter­na­tio­nale. Il y a de l’in­no­va­tion, une volonté d’ap­por­ter une vraie valeur ajou­tée au-delà de ce qui existe déjà, et l’en­vie de pouvoir dire « nous étions là » et « c’était nous » dans quelques temps.

    Le recru­te­ment

    Rien n’est gravé dans le marbre, si vous êtes le mouton à cinq pattes ou si vous avez un parcours très spéci­fique, prenez-contact quand même, ça peut être d’au­tant plus inté­res­sant. Vous trou­ve­rez un e-mail dans les liens à propos ou dans le message qui accom­pagne cette offre.


    Note à ceux qui ont exploré ou explo­re­ront le reste de ce blog : Je n’ex­prime mes opinions poli­tiques et société qu’ici, pas dans les bureaux. Vous n’avez pas à les parta­ger, et je n’ai pas à savoir si vous les parta­gez ou non. Par contre nous parle­rons avec plai­sir de numé­rique, de web, de livre, de tech­no­lo­gie, de culture et de plein d’autres sujets non polé­miques si vous le souhai­tez.

  • Why Flexible Hours Inspire Perfor­mance

    Quels sont les horaires de travail ? J’ai moi même toujours eu du mal à répondre à cette ques­tion. En fait il y a toujours eu des horaires là où j’ai travaillé, comme partout. Malgré tout je ne les ai jamais respecté, ou plutôt je ne m’en suis jamais préoc­cupé. Personne ne m’en a jamais fait le reproche et je suis assez respon­sable pour ne pas profi­ter de cette largesse à mauvais escient.

    J’ar­rive quand j’ar­rive, parfois tôt, souvent tard. Je me rend compte que c’était proba­ble­ment pertur­bant pour certains de mes supé­rieurs ou pour des collègues qui n’avaient pas cette liberté, ou qui croyaient ne pas l’avoir (n’est-ce fina­le­ment pas la même chose ?). Malgré tout, quelle diffé­rence si j’ar­rive à 9h, 9h30 ou 10h tant que je passe la jour­née avec les collègues, que nous avons le temps de discu­ter, d’échan­ger, et que je fais ma dose de travail (souvent en restant plus tard le soir, ou en travaillant aussi de la maison).

    L’his­toire de Marga­ret Heffer­nan recoupe beau­coup de mes impres­sions : Why Flexible Hours Inspire Perfor­mance. Les meilleures équipes dans lesquelles j’ai travaillé fonc­tion­naient entiè­re­ment de cette façon.

    Mes horaires me préoc­cupent d’au­tant moins que mon travail a souvent été de la réflexion. Il ne suffit pas de se mettre à table et de rédi­ger un docu­ment ou de se mettre à penser. Il faut que la ques­tion ait tourné dans la tête pendant quelques jours, quitte à avoir fait tout autre chose. Il faut aussi avoir une bonne idée de ce qui se fait ailleurs, décou­vrir les inno­va­tions, faire de la veille, expé­ri­men­ter des choses même si ce n’est pas direc­te­ment relié à la tâche en cours. Que je sois au travail ou non, les idées murissent, et ça ne se compte pas en heures de travail.

    Pire, respec­ter les horaires c’est arri­ver à 9h quand une demie heure de sommeil aurait été profi­table, ne pas pouvoir rentrer tôt un soir pour passer à la poste et rester stressé, ou simple­ment ne pas travailler quand l’es­prit le veut mais quand un papier nous dit que c’est l’heure. Au final non seule­ment ce n’est pas plus produc­tif mais ça l’est fran­che­ment moins.

    Outre la tranche 10h30 – 16h, qui effec­ti­ve­ment est indis­pen­sable pour que tout le monde se retrouve et pour pouvoir échan­ger avec les tiers, je consi­dère que fina­le­ment les heures n’ont de perti­nence que pour les purs exécu­tants. Les autres, ceux qui font un travail intel­lec­tuel de créa­tion, ont tout inté­rêt à trou­ver eux mêmes leurs horaires. Certains n’y arri­ve­ront pas, mais ceux là n’au­ront géné­ra­le­ment pas l’au­to­no­mie ou l’at­ti­tude respon­sable qu’il faut à un cadre auto­nome. Concen­trez-vous sur les autres, ce sont eux qui font avan­cer la barque.

    Reste un point, celui qui me pose problème : Cette réflexion est assez bien accep­tée dans le milieu ingé­nieur et infor­ma­tique. C’est moins le cas ailleurs. Si je donne cette lati­tude à mes employés, il y a un risque que ces mêmes employés se fassent mal voir de la direc­tion ou des autres collègues. Et ça, c’est un problème que je n’ai pas encore résolu.

  • FileVault 2 easily decryp­ted, warns Pass­ware

    Vous utili­siez FileVault, TrueC­rypt, le Keychain de Mac OS X ou d’autres systèmes de chif­fre­ment du disque ? Il semble qu’au­cun ne soit parfait.

    Si l’im­per­fec­tion n’est pas en soi une décou­verte, qu’un logi­ciel public puisse récu­pé­rer les clefs de déco­dage en moins d’une heure est plus problé­ma­tique.

    Donc voilà : Chif­frez, parce que ça vous protè­gera tout de même contre la plupart des problèmes et que cela ne coûte rien ou presque sur un proces­seur moderne. Par contre n’ou­bliez pas que quelqu’un prêt à inves­tir 1000 $ dans une licence logi­cielle pourra accé­der à vos données.

    FileVault 2 easily decryp­ted, warns Pass­ware

    Contre l’es­pion­nage écono­mique, il n’y a qu’une seule protec­tion : garder le disque dans le coffre fort. Et ne croyez pas que l’es­pion­nage écono­mique est réservé à Airbus ou aux films améri­cains. J’ai entendu plusieurs histoires pour des tailles d’en­tre­prises tout à fait modestes.

  • Google IP Vanda­li­zing OpenS­treetMap

    « We are not evil » qu’ils disent. Moi je veux bien les croire mais visi­ble­ment ils se sont fait prendre à piller des annuaires avec des pratiques commer­ciales malhon­nêtes. Bon, ils se sont excu­sés mais déjà on peut reti­rer la médaille du cheva­lier blanc (et ça fait une belle jambe à la victime).

    Visi­ble­ment il y a des dégats simi­laires sur OpenS­treetMap, qui durent depuis long­temps, via les mêmes adresses IP. On parle de mani­pu­la­tions volon­tai­re­ment malveillantes, de vanda­lisme : Google IP Vanda­li­zing OpenS­treetMap.

    En mettant les deux bout à bout, on peut au moins imagi­ner que certains dépar­te­ments ont oublié le moto de Google. En tout cas il est temps d’avoir non seule­ment des vraies expli­ca­tions (pas unique­ment de simples excuses), et de commen­cer à prendre peur.

    Si Google est honnête, rien ne prédit qu’il le restera toujours. Les diri­geants changent, les équipes peuvent prendre des initia­tives malheu­reuses. Avec leur posi­tion domi­nante, que ferons nous ? Le problème n’est pas nouveau, mais l’ac­tua­lité est un bon support pour s’at­te­ler à la ques­tion.

    Google IP Vanda­li­zing OpenS­treetMap

  • Impri­mante ePaper : nouveauté écolo pour les entre­prises

    Parfois il y a des idées excel­lente. Trans­for­mer toutes nos impres­sions jetables en un affi­chage tempo­raire sur une liseuse à encre numé­rique, ça inter­pelle.

    Bon, on ne rempla­cera pas toutes les impri­mantes, mais un appa­reil 14 à encre élec­tro­nique qui est reconnu sur le réseau comme une impri­mante, qu’on peut prendre en main et qui permet des recherches et des dessins/anno­ta­tions … je prédis un véri­table avenir.

    Il n’y a pas que le côté écolo­gique (qui reste à démon­trer), mais surtout le côté pratique de la chose. Impri­mer des contrats, spéci­fi­ca­tions manuels, mémos, juste pour les relire, les anno­ter et les ranger dans un coin, c’est clair que c’est plus une contrainte qu’autre chose.

    Impri­mante ePaper : nouveauté écolo pour les entre­prises