31 juillet 2014

Libération est encore plus con que moi


Dans mon billet de ce matin, pour rigoler, j'écrivais que Jaurès avait écrit "J'accuse de Zola". 

Libé laisse entendre qu'il a écrit "j'accuse" dans L'Aurore...

Mes huit outils de veille

Thierry nous donne les dix principaux outils qu’il utilise pour faire « sa veille » sur internet. Je vais faire pareil, ça fera un billet à peu de frais. Je ne sais pas si je vais trouver dix outils.

Outil 1 : Google News et sites de presse

En tant que blogueur politique, j’essaie de traiter l’information qui est mises en avant par la presse nationale : j’épluche donc les pages d’accueil de Google News et ce qui est mis en avant par les applications iPad par Le Monde, Le Figaro, Libération et Le Parisien.

J’utilise aussi beaucoup le moteur de recherche de Google News, pour le blog politique comme pour le blog geek, notamment quand j’ai envie de faire un billet mais n’ai pas de sujet… Vous tapez « Facebook » ou « Morano », voire les deux, et vous êtes sûrs de trouver quelque chose à dire !

A noter que je n’utilise plus Google Alert.

Je suis abonné aux alertes du Figaro (suite à une erreur de manipulation) ce qui me permet de voir s'il se passe quelque chose d'important pendant que je fais autre chose... (à noter - ou pas - que je ne suis abonné à aucun outil qui me pushe des alertes dans l'iPhone).

Outil 2 : Twitter

Beaucoup d’informations du blog bistro me sont envoyées par les copains dans Twitter… Sinon, j’essaie de voir les sujets qui font parler, notamment pour tenter de faire un billet qui change un peu de ce qu’on peut lire.

Outil 3 : Talkwalkeralerts

Je suis abonné pour recevoir des informations relatives à quelques sujets mais je n’ai généralement pas le temps de tout traiter…

J’utilise aussi Talkwalker pour faire des recherches dans l’actualité très récente.

Outil 4 : Google Group

Ben oui, les groupes de discussion sont encore le meilleur moyen de recevoir de l’information mais aussi d’en transmettre quand on n’a pas le temps de bloguer.

Outil 5 : Feedly et blogs des copains

Dans le temps, mon reader aurait été en tout début de liste mais les blogs politiques des copains sont de moins en moins remplis : l’information circulant beaucoup dans Twitter, les blogueurs se sont découragés ou ont migré…

Outil 6 : Feedly et blogs geeks

Je suis abonné à un tas de blogs geeks que je ne lis pas vraiment, je me contente de regarder les titres des billets, dans plus de 95% des cas.

Outil 7 : Sites boursiers (Boursorama essentiellement)

Avant l’existence de Twitter, les sites boursiers étaient les premiers à donner les informations comme la presse national prenait encore le temps de réécrire les dépêches d’agence…

Outil 8 : sites institutionnels (notamment de l’Elysée et de l’Assemblée Nationale)

Je lis à peu près tous les comptes rendus des conseils des ministres ou les communiqués officiels. Le site de l’AN me permet d’étudier des textes de lois et, surtout, de lire les retranscriptions des débats.


Et toi ?

28 juillet 2014

Vers un Conseil National de la Blogosphère

C'était le thème de notre déjeuner de travail, ce midi, déjeuner fort simple puisque, à trois, nous n'avons bu qu'une bouteille de vin (une de chaque couleur, s'entend), en plus du champagne, de la bière et du digestif.

Disp en trace les contours ici :
intrigations.blogspot.fr/2014/07/depucelage-de-blogosphere.html

Il parait que je dois en être le Président. Il doit en falloir un gros. 

Mon programme :
1. Obliger Blogger à faire une application iPhone où l'on puisse faire des liens corrects.
2. Empêcher les membres du gouvernement de prendre des conseillers en numériques des types qui gagnent du pognon avec le numérique. 
3. Rétablir l'absence de règle pour les blogowars et les insultes diverses. 
4. Promouvoir les blogs qui produisent du contenu par rapport à des médias qui ne font que reprendre des dépêches d'agence.
5. Former les acteurs du web au nouveau format de ce machin pour qu'ils puissent arrêter de "penser papier". 
6. Obliger le gouvernement à se séparer de tous ses conseillers en numérique qui baignent dedans depuis des années et qui n'ont aucune idée de ce que fait le grand public. 
7. Baisser les taxes sur la bière (dans les bistros avec wifi). 

23 juillet 2014

Vive Foursquare !

Ces braves gens m'envoient un mail pour me remercier d'utiliser Foursquare depuis cinq ans. À mon tour de les remercier. Je ne savais pas que j'étais aussi vieux dans ce truc totalement inutile. 

Cela étant, le mail est en anglais, bien trop long, je ne lis pas. 

Cela toujours étant, il faudrait qu'ils arrêtent de nous bassiner avec leur nouveau truc, Swarn, si ma mémoire est bonne. On n'y comprends rien, ça bouffe de la batterie. Et ça sert à rien : je ne veux pas retrouver des copains des réseaux sociaux dans la vraie vie mais des copains de la vraie vie dans les réseaux sociaux. 

Revenez aux vraies valeurs inutiles : on veut être Mayors de conneries. 

22 juillet 2014

10 astuces pour gérer ses mails

L’ami Disp revient sur son blog sur les astuces pour gérer ses mails sur la base d’un article de Challenges. Nous ne serons pas trop de deux pour lui répondre. C’est en 10 points.

Point 1 : Qui a réellement besoin de mon message ?

Point de vue de Challenges : il faut bien travailler les destinataires, voire leur demander s’ils veulent l’être.
Point de vue de Disp : on est en France, on est foutu, les destinataires sont mis là comme parapluies.
Point de vue de moi : il faut travailler le contenu pour que le destinataire en copie sache s’il faut qu’il lise avec attention. Il faut aussi être intransigeant avec les gens qui répondent à tort à des mails pour lesquels ils ne sont qu’en information.

Point 2 : Quel est le délai maximal pour répondre ?

Point de vue de Challenges : soit répondre dans les 48 heures soit demander pour quand il faut la réponse.
Point de vue de Disp : cette question est conne. Par ailleurs, il faut faire attention au temps de lecture des pièces jointes qui peuvent être des pièges.
Point de vue de moi : heu… Dans la mesure du possible, il faut répondre le plus rapidement possible (sauf aux casse-couilles) car on ne sait pas quel est le délai de l’autre. Néanmoins, si la réponse est longue à faire, on n’hésitera pas à refuser de répondre et, surtout, à sous-traiter la réponse à un collègue, un chef ou un sous-fiffre. Je ne déconne. Il m’arrive de faire suivre un mail à mon chef et lui demandant ce que je dois répondre (et je réponds aux mails qu’il me fait suivre).

Point 3 : Comment valoriser ce qui est important et/ou urgent?

Point de vue de C : z’avez qu’à lire, je suis d’accord.
Point de vue de D : c’est le bordel.
Point de vue de m : je n’utilise pas l’option des machins de messagerie qui permet de catégoriser des mails en important. J’essaie d’être clair dans ce que j’envoie et si le lascar qui m’envoie un mail n’est pas clair, son mail passera automatiquement dans la poubelle. Hop !

Point 4 : Quand et comment mettre fin à un échange ?

Point de vue de C : bof.
Point de vue de D : bof aussi.
Point de vue de m : ça dépend.

Point 5 : Comment gérer le flux au quotidien ?

Point de vue de C : il faut savoir se déconnecter, fermer sa messagerie, mais peut-être pas plus de deux heures pour ne pas louper d’urgence.
Point de vue de D : ce n’est pas nécessairement le mail qui provoque les distractions.
Point de vue de m : on s’en fout. La messagerie est devenu le principal outil de travail, il faut s’y faire et savoir se concentrer sur son job.

Point 6 : Comment ranger ses mails ?

Point de vue de C : il faut bien ranger ses mails.
Point de vue de D : il ne faut pas ranger ses mails.
Point de vue de m : il ne faut surtout pas ranger ses mails. Il faut seulement pouvoir retrouver ceux qui ont une valeur contractuelle forte : proposition commerciale, acceptation d’un devis,…  Pour le reste, je connais des gens qui passent plus de temps à ranger (y compris avec d’excellentes méthodes) et à rechercher des mails que moi à en trouver. Les miens étant traités au fil de l’eau, je n’ai jamais de recherche à faire, sauf pour retrouver des pièces jointes que je n’aurais pas pris la peine d’archiver, considérant que ce n’est pas à moi de le faire… En outre, la plupart des échanges par mail remplacent ce qui aurait pu être dit en réunion ou au téléphone : ça ne s’archive pas…

Point 7 : Comment ne pas se laisser envahir ?

Point de vue de C : ne pas hésiter à mettre en spam ou à se désinscrire de newsletters.
Point de vue de D : faire avec et s’en foutre…
Point de vue de n : comme D. Je traite ce que j’ai le temps de traiter. Si j’oublie un truc, l’expéditeur n’a qu’à me relancer. S’il ne le fait pas, c’est que sa demande était inutile.

Point 8 : Comment les signer ?

Sobre. Tout le monde est d’accord.

Point 9 : Que faire des mails personnels ?

Point de vue de C : avoir une boite mail séparée ou faire attention à ce qu’ils soient marqués comme « personnel ».
Point de vue de D : il faut un point de vue juridique.
Point de vue de n : il est exceptionnel que je reçoive un mail perso sur mon adresse d’entreprise et je n’utilise jamais cette dernière pour envoyer des messages perso. A mon avis, du moment que les messages restent exceptionnels, l’employeur s’en fout.

Point 10 : Et pendant mes congés, je fais quoi ?

Point de vue de C : qui donne trois conseils. Le premier : désigner quelqu’un pour regarder votre boite. Le deuxième : consulter ses messages une fois par jour. Le troisième : avoir un message d’absence indiquant un remplaçant.
Point de vue de D : déconnecter.
Point de vue de n : l’important est d’avoir un bon message d’absence qui indique votre date de retour. N’y citer un collègue que pour faire face aux urgences, en aucun cas pour vous remplacer sauf si vous prenez des vacances hors vacances scolaires.

Compléments

Disp conclut ainsi : « Il reste bien d'autres questions. L'email est-il vraiment un progrès ? Après l'email, quels seront les outils ? Peut-on remplacer par du chat ? Comment fusionner l'email et tous les autres flux ? ... » Oui, l’email est un progrès. Il y aura forcément un outil après lui mais ça ne changera pas grand-chose, l’email fusionnera avec d’autres flux. Le chat est à proscrire sauf s’il est réellement nécessaire.

Hop.

17 juillet 2014

La programmation orientée objet pour les nuls (et les cheffs)

Cela faisait des années que je n’avais pas entendu parler de ce concept fumeux de « Programmation orientée objet ». C’est l’ami Disp qui l’évoque dans son blog, aujourd’hui.  Amis informaticiens, ne ronchonnez pas ! Je sais que vous utilisez ce truc au quotidien. Je ne dénigre pas les développeurs mais uniquement leurs chefs.

Disp pousse un cri : « La POO n’est pas morte ! »

Néanmoins, je n’oublie pas qu’une partie de mes lecteurs sont des lascars qui ne connaissent rien à la programmation orientée objet. Je vais leur expliquer. Vous connaissez Candy Crush ? A l’écran, on va dire qu’on a des bonbons de différentes couleurs, disons des rouges des bleus, des jaunes et des verts, pour simplifier. Chaque bonbon a des caractéristiques communes : descendre d’un cran s’il n’y a personne en dessous, pouvoir être déplacés d’un cran, occuper la place de celui qui vient prendre sa propre place, être détruit dans certaines conditions (si les voisins sont identiques par exemple). On va dire que chaque bonbon est un objet. Tous les bonbons ont les caractéristiques que je viens de citer. Mais les bonbons de chaque couleur ont des caractéristiques différentes. Les bonbons jaunes rigolent quand on leur caresse les nichons, les rouges chantent la marseillaise en breton, les bleus boivent de la bière quand on a les yeux tournés et les verts racontent des conneries dans leurs blogs. Parmi ses caractéristiques différentes, n’oublions pas l’essentiel : la couleur et le fait qu’ils soient d’une même famille pour être détruits quand ils sont alignés.

Le mec  qui développe, il va définir ce qu’est l’objet bonbon avec les caractéristiques  principales, puis définir les bonbons des quatre couleurs qui « hériteront » des caractéristiques décrites dans les bonbons et avoir les caractéristiques propres. Ainsi, si vous avez trente bonbons à l’écran, le développeur n’a pas… développé trente bonbons mais un seul objet et ses quatre petits frères.

Normalement, à ce stade, vous avez tout compris de la programmation orientée objet. Je vais quand même continuer au cas où vous seriez très con.

Candy Crush est composé d’un certain nombre de tableaux, avec chacun un objectif (dépasser un certain nombre de points, casser toute la glace,…). Les tableaux ont ceci en commun : ils ont une ou plusieurs grilles dans lesquelles on pourra mettre les bonbons. Dans chaque grille, nous avons des cases, à peu près toutes identiques, d’un point de vue du développeur : une case peut contenir un bonbon ou être bouchée par du chocolat. On va donc définir un objet case, avec un attribut : ce qu’elle contient. Soit du chocolat, soit un bonbon. On va ensuite définir l’objet grille, qui sera composé d’un certain nombre de cases, définies sur la base de l’objet case.

Le développeur pourra ainsi se baser sur l’objet « grille » pour définir ses différents tableaux. Et tant qu’à faire vous créez des objets « tableau ».

Voila, c’est tout ! Ou presque, il faudra ajouter quelques milliers d’heures de travail pour faire fonctionner ce qu’un blogueur a écrit avant d’aller au bistro.

J’arrête mes explications. Si vous n’avez rien compris, vous pouvez chercher « programmation orientée objet » dans Google. Si vous n’avez pas de bol, vous tomberez sur le présent billet.

Mise en pratique

Vous allez donc réunir une équipe de développeurs. Celui pour l’objet bonbon, ceux pour chacun des bonbons de couleur, celui pour la case, celui pour la grille, quelques-uns pour les tableaux. Vous êtes le chef : vous pourrez aller boire une bière pendant qu’ils travaillent. Mais avant, il faudra leur dire précisément quoi faire et comment utiliser les objets définis par les autres.

C’est tout con, hein ?,  vu comme ça.

A notons qu’après avoir créé les objets « bonbon », nous pourrions les utiliser pour créer d’autres jeux, comme Jelly Mania qui ressemble à Candy Crush mais avec des yaourts. Il faudrait donc créer un « objet objet » destiné à occuper des cases dans les jeux. Les objets bonbon de Candy Crush et les objets yaourt de Jelly Mania hériteraient de leurs caractéristiques.

Hop !

Et sans objet ?

Imaginions que le dieu de l’informatique n’ait pas inventé la programmation orientée objet et que nous devions développer Candy Crush pour gagner beaucoup de sous pour payer beaucoup de bière. Comment ferions-nous ? Nous ne pourrions pas définir des objets bonbon, des objets bonbon vert, rouge, bleu et jaune, des objets case, des objets grilles et des objet tableau. Nous serions bien emmerdés et resterions à nous caresser les couilles en regardant l’écran.

L’objet est utile. J’espère que j’ai rassuré Disp.

Nous avancerions quand même. Nous n’allons quand même pas programmer chaque bonbon de chaque case de chaque grille indépendamment ! Nous créerions donc un certain nombre de fonctions pour gérer tout ça, ça serait vachement lourd et compliqué.

Mais, au final, nous n’aurions rien fait d’autre que de créer des objets, finalement… Nous aurions des bonbons de différentes couleurs, des grilles,…  Mais ce ne sont pas milliers d’heures que nous y aurions consacré mais des dizaines de milliers.

La programmation orientée objet est donc très utile. C’est une bonne méthode de programmation. Mais ce n’est qu’une méthode de programmation qui se découle en langages de programmation, les plus connus actuellement sont probablement PHP, Java, C++,…

Avec eux, on peut créer facilement des objets bonbon.

De la critique utile de la programmation orientée objet

Tout  d’abord et pour commencer, elle n’est pas adaptée pour tout. Plus précisément, elle n’est pas l’idéale pour tout. L’intérêt est : qui peut le plus peut le moins. Beaucoup de développeurs utilisent des langages dits « objet » mais c’est donner de la confiture aux cochons. Les amateurs de confitures doivent être formés et ça coûte des sous. En fait, dans beaucoup d’applications, les objets sont uniques. Par exemple, si vous faites une version de démonstration de Candy Crush avec un seul tableau, ce n’est pas la peine de créer un objet « tableau » ni même un objet « grille ». Dans le temps, on se passait très bien des objets. Du moins, on en faisait comme Monsieur Jourdain. Il faisait des objets sans le savoir.
Ensuite et pour poursuivre, si elle n’est pas adaptée pour tout, elle induit en erreur parce que des développeurs sobres pourraient dire : « tiens je vais faire de l’objet », or il n’en fait pas. Il fait de l’informatique traditionnelle. Cela génère des bugs et autres dysfonctionnements. C’est mal.
Enfin et pour terminer, il faut faire un peu d’histoire.

Un peu d’histoire

La programmation orientée objet est relativement ancienne (Wikipedia est ton ami) mais elle est devenue à la mode dans les années 80. A mon expérience personnelle, je pourrais dater cela de 86 ou 87. On ne parlait plus que de ça. Les entreprises voulaient découvrir ce qui serait la programmation du futur.

C’était très rigolo car nous avions des gens avec de cravates et du poil dans les oreilles, généralement on appelle ça des directeurs et des consultants, qui parlaient objet sans absolument savoir de quoi ils parlaient, confondant une méthode de programmation avec une méthode d’analyse. C’est dommage, Candy Crush n’existait pas à l’époque, mais ils faisaient très sérieusement ce que je faisais en déconnant ! Oui ! C’est génial, on va créer un objet bonbon, puis un bonbon vert et un bonbon rouge. Ou un yaourt, je ne sais plus, n’essayez pas de m’embrouiller.

Ils ne savaient absolument pas de quoi je parlais. Je suis prêt à parier, d’ailleurs, qu’une partie des développeurs qui font des objets aujourd’hui ne savent même pas quelles sont les conséquences : allocation de mémoire et tout ça.

Dans les années suivantes, ils ont obligé leurs équipe à faire de la programmation orientée objet mais en insistant sur l’aspect « objet » parce que ça fait bien, pas sur le langage de programmation lui-même, vous savez, le truc qui permet d’écrire « class bonbon » pour créer l’objet bonbon. Ces valeureuses équipes se sont retrouvées à réécrire leurs logiciels en remplaçant les fonctions par des classes parce qu’ils ne savaient pas quoi faire d’autres, leur chef leur a dit de faire des objets. Je n’abuse pas, y compris parmi les paradoxes du présent paragraphe. C’était un bordel monstre.

Je pourrais vous raconter quelques anecdotes mais ce billet est trop long, d’autant qu’à peu près à la même époque, il y a eu une autre révolution : la généralisation de Windows. Passant d’un environnement « mono tâche » en MS-DOS, les boites se sont trouvées à passés à Windows et en ont profité pour faire le passage à l’objet (ce qui était une bonne idée) dans un joyeux bordel, sans penser réellement à l’avenir de leurs applications…

Mais pendant toutes cette phase, les « maîtrises d’ouvrage » (la partie des informaticiens qui ne font pas d’informatique mais font la relation entre les utilisateurs et les développeurs) ne sont pas restés à glander. Ils ont voulu créer « la conception orientée objet » et tout est parti en couilles.

Mais c’est une autre histoire.

16 juillet 2014

Comment j'ai appris l'informatique dans les années 80

Alors qu’on parle de l’enseignement de la programmation en primaire, je me rappelle de mes cours d’informatique, quand j’étais étudiant, de septembre 84 à juin 87, en gros. C’était à une autre époque. Les écoles avaient du mal à trouver des profs compétents et on avait très peu de matériel. La première année d’IUT, on n’avait qu’un « Mini 6 » de Bull, c’est vous dire !

Travailler ainsi était une galère et la plupart des étudiants n’avaient jamais réussi à compiler un programme. On travaillait par binôme, ce qui était une aberration. Le type qui bossait avec moi s’en foutait et récupérait des bonnes notes.

J’avais appris la programmation bien avant de rentrer à l’IUT, à 13 ans, si ma mémoire est bonne. Je « parlais » couramment le Basic et je me débrouillais un peu dans les machins de l’éducation nationale.

A l’IUT, j’ai appris le Pascal, ce qui m’a bien rendu service ensuite, et le Fortran, ce qui était complètement con. Après l’IUT, j’ai fait une école privée d’informatique, destinée à la reconversion des chômeurs. J’avais choisi ce machin parce que c’était rémunéré… et parce que j’étais refusé dans toutes les formations en informatique du genre Miage, n’ayant pas le niveau. A posteriori, ceci est très drôle vu que j’étais quasiment le seul de l’IUT à savoir réellement programmer en sortant. Près de trente ans plus tard, c’est encore plus drôle vu que je suis probablement le seul à avoir fait une belle carrière dans l’informatique.

Ce qui me fait dire, d’ailleurs, que l’enseignement de l’informatique est largement merdique en France, ou, du moins, l’était à cette époque. D’ailleurs, en 1987, j’avais intégré une SSII. Beaucoup de mes collègues avaient une formation qui n’avait rien à voir avec l’informatique. Ceux qui avait un DUT informatique étaient réellement nuls ou, du moins, avaient un très mauvais esprit : ils s’imaginaient meilleurs que tout le monde. Ceux qui avaient une vraie formation informatique voire un diplôme d’ingénieur dans une matière proche avaient tellement les dents longues qu’ils ont probablement fini sous-chef de service dans une entreprise à la con.

Toujours est-il que dans cette école privée, j’ai appris le COBOL. Je l’ai un peu pratiqué de manière professionnelle pendant les six mois après le stage et, surtout, cela m’a aidé pendant ma carrière parce que je pouvais comprendre ce que faisaient les informaticiens du « back office ». D’ailleurs, près de 30 ans après, c’est moi qui fais les relations entre le back et le front dans la boite.

Dans ces années, le Pascal était à la mode. C’est un langage qui avait été créé pour l’éducation et certaines entreprises informatiques en avaient fait leur langage de développement, pensant qu’il serait l’avenir (C a pris la place et a du de nombreux descendants). Je l’ai beaucoup utilisé pour le boulot entre 1988 et 1993. Turbo Pascal avait révolutionné le monde de la programmation et c’était délirant de voir qu’à l’IUT nous avions encore des vieux compilateurs pourris…

Reprenons. J’ai fait un DUT de Statistiques. L’informatique n’était pas la matière principale mais y avait une place de choix après les statistiques, les probabilités et les maths, au même niveau que l’économie. Ensuite, j’ai fait un an d’école d’analyste fonctionnel. Si ! Ca existe. La programmation n’était pas au cœur de la formation.

Cette école était totalement bidon : elle touchait des subventions de l’Etat pour réorienter la formation de chômeurs (ce que je n’étais pas réellement). C’était de l’escroquerie sauf pour ce qui concerne la matière principale : l’analyse fonctionnelle pour laquelle le prof était réellement bon mais, à part moi qui voulait réellement apprendre, n’avait pas le bon public. J’ai d’ailleurs beaucoup appris, ne serait-ce qu’au niveau de la rigueur nécessaire à l’analyse pour tenter de couvrir l’exhaustivité des traitements. Le prof de comptabilité analytique était un abruti, un étudiant qui faisait des vacations et que les autres adulaient pour des raisons qui m’échappaient, jusqu’au jour où je l’ai cassé en cours, en lui démontrant les erreurs qu’il commettait. Je me demande pourquoi on avait des cours de comptabilité analytique dans cette formation et je mentionne cela à titre d’exemple.

L’enseignement de l’informatique était ainsi fait. Les écoles faisaient n’importe quoi. Elles recevaient de l’Etat la mission de former des jeunes à la programmation et trouvaient des professeurs vacataires sans pouvoir vérifier leurs compétences tant au niveau de l’informatique que de la pédagogie. A l’IUT, le premier prof d’informatique qu’on a eu était le prof de probabilité qui avait vaguement appris la programmation pendant ses heures de loisir. Il pratiquait un enseignement purement théorique (on rendait les « devoirs » sur papier…) et n’avait aucune idée de ce qu’était l’utilisation de ce bordel dans un environnement professionnel. Le second était plus efficace car beaucoup plus jeune, beaucoup plus branché informatique et comprenant de quoi il parlait. Il n’empêche qu’il avait été recruté par petites annonces. C’était un ancien élève de l’IUT qui tenait maintenant l’hôtel de sa mère et avait développé en Pascal les programmes nécessaires à sa gestion. Voila pour son CV.

Voila pourquoi je suis circonspect quand je vois que le ministère a consulté les associations en juin pour développer l’enseignement du « code informatique » en primaire à la rentrée… Même 30 ans après.

13 juillet 2014

L'informatique à l'école

Benoît Hamon a annoncé différentes mesures pour l'informatique à l'école, comme l'apprentissage du code informatique à l'école, et je l'évoque dans mon billet politique du jour. J'y suis opposé. René Paul Henri me qualifie de « rétrograde » et Suzanne vient un peu à mon secours en rappelant des échecs de différents plans et en insistant sur le fait qu'il faille d'abord éduquer les enfants à l'apprentissage de l'outil informatique, en commençant par la dactylo.

J'aurais pu leur répondre longuement dans les commentaires mais quand on a l'occasion de faire un billet de blog, on s'y jette !

Tout d'abord, une des erreurs qui sont faites par la plupart des adultes y compris le personnel politique est de se baser sur ses propres connaissances pour définir ce qu'est l'informatique, voire le métier d'informaticien que l'on qualifie comme le métier d'avenir, celui qui permettra à la France de s'en sortir... et comme ce qui semble le plus évident dans ce métier est « la programmation », on en vient à des âneries comme la nécessité d'apprendre « le code informatique » à l'école.

Je le remarque également à mon boulot, alors que je bosse au sein d'une DSI, au sein de personnes parfaitement compétentes mais souvent incapables de voir au delà des technologies qu'ils connaissent, de ce qu'ils ont appris, du travail qu'ils ont à mettre en œuvre. J'ai déjà raconté cette anecdote : vers 2004, je suis arrivé dans un service où une personne était en charge des statistiques. Il recevait des paquets de listing et passait environ trois semaines à en faire des récapitulatifs. J'ai envoyé un mail à la personne qui produisait les listings. Je lui ai demandé s'il pouvait me les envoyer sous forme de fichiers informatiques. Elle l'a fait. J'ai incorporé les fichiers dans Excel et le temps de me lancer, en quelques mois, je faisais le même boulot que mon collègue en cinquante minutes. En changeant les outils, j'avais divisé environ par 100 un temps de traitement. Pour des aspects sociaux, on n'avait pas dit à mon collègue qu'il ne servait plus à rien, on avait donc continué à lui faire sortir les statistiques officielles, celles présentées au conseil de direction, mais on avait commencé à utiliser les miennes pour améliorer le fonctionnement de nos systèmes.

Après quelques temps, j'avais été voir le directeur. Je lui avais dit : « dis donc, ça commence à me casser les burnes, de perdre 50 minutes par mois à croiser des chiffres dans Excel, tu ne pourrais pas me prendre un stagiaire pendant deux ou trois mois pour développer des macros pour automatiser tout ça ? » Je me suis alors rendu compte de deux choses : la première est qu'il ne savait pas qu'on puisse faire des macros dans Excel (tiens, si tu ne sais pas non plus, je vais t'expliquer : dans Excel on peut faire des programmes informatiques, du code, comme on dit, pour automatiser des traitements), la deuxième est qu'il ne pouvait pas imaginer qu'un lascar comme moi qui connaissais assez bien Excel ne pouvait pas le connaître au point de ne pas savoir faire de la programmation avec.

Je vais raconter une deuxième anecdote. Nos logiciels sont installés en France mais aussi dans des patelins comme Monaco où nous avons des filiales. Monaco n'est pas la France. C'est un autre pays. En informatique, les pays sont identifiés par des « codes pays ». Récemment, un jeune collègue avec 7 ou 8 ans d'expérience vient me demander où il pouvait trouver le code pays de Monaco, à qui il pouvait demander,... En fait, il espérait probablement que je le connaisse par cœur, ce qui n'est pas le cas. J'ai pris mon navigateur, j'ai tourné mon écran vers lui et je lui ai dit « regarde comment on fait des recherches pour le travail ». J'ai lancé Google, j'ai tapé « code pays iso monaco » et la réponse est arrivée en trois secondes (le temps de voir où Google l'avait affichée).

Ce type, par ailleurs, ingénieur en informatique, n'avait pas pensé à utilisé Google pour avoir une réponse dans le cadre professionnel.

Pourquoi je vous raconte toutes ces histoires ? Parce que l'on voit que des professionnels de l'informatique (un vieux développeur, un directeur de service, un jeune ingénieur,... et je pourrais multiplier) n'ont pas l'esprit assez ouvert pour imaginer ce que l'on pourrait faire de ce bazar...

Or, ce sont à peu près les mêmes qui font des programmes scolaires et qui vont développer des plans pour permettre à des gamins d'apprendre l'informatique, le tout enseigné par des gens qui n'ont pas les compétences (ce n'est pas une critique, on ne peut pas être bon partout),... Après échec, le tout sera moqué par des lascars qui se croient plus intelligents que tout le monde, sur le mode : « ah ah ah, le plan informatique pour tous ! ».

Pour apprendre à taper sur un clavier, il faut un prof de dactylo, pas un prof d'informatique, pas un instit. Pour apprendre à taper un texte cohérent, il faut un prof de français, pas un prof de sciences doué pour l'informatique. Pour décider quelles technologies enseigner à l'école, il ne faut pas un lascar qui reproduise ce qu'il a lui même appris quand il était en fac.

Il y a cinq ans, est-ce qu'une personne dans les ministères aurait pensé qu'il allait falloir apprendre aux gamins à utiliser des tablettes, parce que ça allait exploser dans les années suivantes ? Je parlais d'apprendre la dactylo et vous avez applaudi bêtement tant cela paraît évident que pour bien utiliser un ordinateur, autant savoir utiliser correctement un clavier, ce qui évite de se concentrer sur la position des touches quand on travaille... Mais c'est complètement con ! Les claviers des tablettes sont tellement merdiques que l'on finira par écrire directement sur l'écran avec un stylet, voir sur un papier avec un crayon et qu'on numérisera le tout ensuite...

Et l'on voudrait décider dans les ministères ce pourquoi il faudrait former des enseignants pour qu'ils donnent des leçons aux gamins pour des trucs de nouvelles technologies qui seront dépassées au moment de leur mise en pratique ? Déjà, dans les écoles d'informatiques, ils sont nécessairement dépassés par la vitesse d'évolution de ces machins (trouvez moi un prof qui ait déjà développé une vraie web application pour smartphone en HTML5...), les écoles primaires devraient être au top ?

Restons calmes...

04 juillet 2014

Cinq conseils de savoir-vivre pour les mails professionnels

Je me rappelle cette fin d’année 1996 où, pour la première fois, je me suis retrouvé avec une adresse mail professionnelle. Ainsi, en une vingtaine d’années cet outil magnifique s’est démocratisé. Parallèlement, les utilisateurs ont développé des usages, comme s’il fallait se précipiter à respecter un manuel du savoir-vivre qui n’existe pas. J’évoque périodiquement les problèmes liés aux mails, le fait que l’on soit souvent submergés et je donne parfois des conseils mais il est temps de revisiter ces usages qui sont parfois complètement cons. Il faut le dire.

Je vais illustrer. Tu as vu l’image, là en haut à gauche. C’est la fin d’un mail que je viens de recevoir. La formule de politesse n’est pas dans la même police de caractères que la dernière ligne de texte et est par ailleurs formulée en français et en anglais. La conclusion est évidente : l’expéditeur l’a incluse au « pied » de son mail (signature automatique) dans le machin inséré automatiquement avec ses coordonnées, son numéro de téléphone,… A quoi rime une formule de politesse si elle est automatisée dans un échange avec une personne que l’on connaît bien.

Ce qui nous amène aux deux premiers conseils.

Conseil 1 : n’automatise pas ta formule de politesse.

Le « cordialement » est d’usage dans de nombreux cas. Il remplace le « Je vous prie d’agréer l’expression de mes salutations distinguées ». Ne l’utilisez pas si vous connaissez bien la personne, ça serait grotesque. Pour ma part, je signe « A+, Nicolas » dès lors que nos relations dépassement vaguement le strict cadre du travail. Voire « A+, N. ». Voire « Nicolas ».Voire « N. ». Voire rien si nous avons déjà échangé par mail dans la journée.

Le « cordialement » est d’usage mais ne s’impose pas. Un « bonne soirée » ou un « bon week-end » sera beaucoup plus personnel (s’il est adapté et donc plus sympathique).

Conseil 2 : soigne ton pied de mail (signature automatique)

Evidemment, si l’entreprise impose un format, tu dois le respecter. Au cas contraire, il doit contenir le plus faible nombre d’information possible : le nom de l’entreprise, de la direction et le numéro de téléphone. Mentionner ce dernier est indispensable.

J’ai toujours envie d’égorger les types qui ne le mettent pas, ça m’oblige à gérer un annuaire…

Conseil 3 : réfléchis bien à l’entrée en matière

L’usage est de commencer par « Bonjour, ». Je conseille d’ajouter le prénom des destinataires. Exemple : « Bonjour Jessica et Roger ». En commençant par les gonzesses même si ce n’est pas conforme à l’égalitarisme de rigueur chez les progressistes. Ajouter les prénoms permet de personnaliser et de donner une touche informelle mais aussi d’indiquer aux gens qui sont en copie qu’ils ne peuvent lire qu’en diagonale.

On peut aussi ne rien mettre, notamment si on a déjà vu la personne, mais aussi si le mail est très court, j’y reviendrai, ou si vous répondez à un mail. Par exemple, un type vous demande si vous êtes disponible pour une réunion à telle heure tel jour. La réponse pourra être « Oui. Cordialement. Nicolas. » Faire plus est une perte de temps.

Conseil 4 : n’ayez pas peur d’être grossier

Je parlais des différentes formules de politesse. Il est bien plus grossier d’avoir un machin qui ajoute automatiquement un « cordialement » que de ne rien mettre ou d’oublier un « bonjour ». Voir le conseil 5 : il faut faire court. Ainsi, il faut aller droit au but.

Quand vous faites une demande, vous n’avez pas à vous justifier sauf si vous demandez l’impossible (c'est-à-dire une réponse très rapide).

Conseil 5 : faire court

C’est un conseil que je donne souvent parce que ça évite à vos destinataires de perdre du temps à lire. S’il y a des explications à donner et que vous les jugez intéressantes, faites les en « P.S. », après la signature.

Le dernier mail que j’ai envoyé à mon directeur contenait une ligne, du genre : « ce qu’on nous a demandé est conforme à la réglementation ». L’objet précisait le cadre. Je n’avais pas à lui en dire plus, il n’en aurait rien eu à faire, alors que, à ma place, la plupart des loustics auraient pondu quatre ou cinq lignes, voire beaucoup plus, pour démontrer leur propos, indiquer qu’ils avaient travaillé, fait des recherches,… ce dont tout le monde se fout.

Le « faire court » a plusieurs intérêts, notamment celui d’habituer vos interlocuteurs à faire pareil ce qui vous évite de lire leurs conneries. Mais, pour ce qui nous concerne, le « nouveau savoir-vivre », ça leur évite de perdre du temps à lire les vôtres.

Faites en bon usage !