Catégorie : Technique

  • À quoi ça sert

    Quand vous aurez tous vos conte­nus sur Amazon, toute votre commu­ni­ca­tion sur Google et toutes vos rela­tions sur Face­book, et que deux ans après l’un des trois ou les trois vous dit « vous signez ici ou vous aban­don­nez tout ce que vous avez », il sera un peu tard.

    Ce scéna­rio n’est même plus de la prédic­tion, c’est le présent et ça a déjà commencé. Le billet précé­dent sur la messa­ge­rie instan­ta­née n’est qu’une anec­dote, mais qui fait partie d’un mouve­ment de fond bien puis­sant.

    Ce qui m’agace le plus c’est que les gens laissent faire, et même semblent ne pas s’en préoc­cu­per.

    Parfois j’ai presque envie de lais­ser tomber le web à tel point je me dis « c’est foutu les gens s’en moquent ».

    J’ai l’air bien beau à résis­ter en contrô­lant mes adresses et mes iden­ti­fiants avec mon nom de domaine, voire mes services sur mon serveur perso. C’est utile pour moi mais ce n’est acces­sible qu’à une mino­rité. Mener le combat seul ne sert à rien : Si vous vous êtes tous vendus, alors pour conti­nuer à vivre en rela­tion avec vous je n’ai d’autre choix que de faire de pareil.

    Seuls nous n’avons quasi­ment aucune chance de propo­ser une alter­na­tive, pour­tant c’est juste essen­tiel pour nous, notre avenir, et celui de nos enfants. Si ça vous parait encore être une « grande phrase », c’est que vous ne réali­sez pas encore ce qui se joue aujourd’­hui.

  • Messa­ge­rie instan­ta­née et jardins fermés

    Je suis très pessi­miste sur les évolu­tions récentes dans la messa­ge­rie instan­ta­née.

    Le mieux

    Pendant un temps ça s’est un peu amélioré. Les non-tech­ni­ciens ne le voyaient pas mais on a commencé à ouvrir un peu les réseaux. Le proto­cole ouvert et stan­dar­disé XMPP s’est plus ou moins imposé comme base, et Jabber (le réseau des serveurs XMPP ouverts) commençait à prendre pas mal d’im­por­tance.

    Apple iChat, Google et même MSN savaient désor­mais plus ou moins commu­niquer entre eux via ce proto­cole, éven­tuel­le­ment avec quelques arti­fices. Chacun pouvait aussi monter son propre sous-réseau chez lui ou dans son entre­prise, avec sa propre adresse, et commu­niquer avec les gros réseaux de façon trans­pa­rente. Même Skype avait annoncé déve­lop­per un connec­teur pour la partie texte de sa messa­ge­rie. AIM avait de plus commencé à s’ou­vrir au réseau de Google, ce qui était un premier pas.

    Mais ce n’est pas tout : AIM, ICQ, Yahoo! Face­book et bien d’autres ont migré vers ce même proto­cole.Même si leurs réseaux restent isolés les uns des autres, il était possible d’uti­li­ser le même proto­cole et donc d’avoir des appli­ca­tions qui faisaient tout. C’était encore loin d’être idéal, parfois les fonc­tion­na­li­tés avan­cées des diffé­rents réseau n’étaient pas gérées, et pour certains l’im­plé­men­ta­tion était expé­ri­men­tale ou en déve­lop­pe­ment, mais la direc­tion était plus qu’en­cou­ra­geante. Même twit­ter avait une inter­face avec le proto­cole XMPP pour certains flux.

    Les appli­ca­tions Pidgin et Adium permet­taient ce qui manquait encore, en implé­men­tant tous les proto­coles prin­ci­paux. Sous réserve d’avoir un compte sur chaque réseau il était possible de centra­li­ser toute la messa­ge­rie sur une seule appli­ca­tion et de ne pas se préoc­cu­per de savoir qui est sur quel réseau (ou même qu’il existe diffé­rents réseaux).

    Il n’y a presque que Skype qui restait dans son coin mais, au moins dans nos pays, il était quasi­ment exclu­si­ve­ment utilisé pour la voix, pas pour la messa­ge­rie instan­ta­née.

    Et le moins bien

    Malheu­reu­se­ment le « je veux mon réseau social comme Face­book » semble être à la mode et on a tout détri­coté tout juste quelques mois.

    Twit­ter ? Ils ont fermé leur inter­face XMPP, et les évolu­tions montrent qu’ils tentent de contrô­ler les diffé­rentes appli­ca­tions clientes. Le nombre maxi­mum d’uti­li­sa­teurs par appli­ca­tion non-offi­cielles fait qu’il est illu­soir d’ima­gi­ner une compa­ti­bi­lité stable et pérenne avec des appli­ca­tions de messa­ge­rie instan­ta­née.

    MSN ? Ils ont racheté Skype et a annoncé migrer ses utili­sa­teurs de Windows Live vers ce réseau. Le réseau MSN fonc­tionne encore alors que sa date d’ex­tinc­tion est désor­mais passée, mais rien ne permet de dire si ça perdu­rera encore long­temps.

    Le proto­cole Skype n’est malheu­reu­se­ment pas ouvert et ce ne semble pas être la direc­tion souhai­tée en interne. Il est probable qu’il faille désor­mais commu­niquer avec les contacts MSN via Skype et unique­ment Skype.

    Il existe encore un plugin Skype pour Pidgin mais il impose d’avoir le client Skype lancé et connecté, ne couvre pas le mobile, et semble ne pas fonc­tion­ner correc­te­ment pour les utili­sa­teurs qui ont fusionné leur compte Skype et leur compte MSN.

    Google ? Google vient d’an­non­cer le passage à Hangout. Ils avaient déjà éteint un bref moment les échanges entre leurs serveurs de messa­ge­rie et les serveurs tiers, rompant l’in­te­ro­pé­ra­bi­lité. Désor­mais c’est tout le proto­cole XMPP qui est jeté. Impos­sible de commu­niquer avec des utili­sa­teurs non Google une fois que vous avez migré, pas même avec les utili­sa­teurs du réseau AIM qui avaient une liai­son spéci­fique. Impos­sible aussi d’uti­li­ser un client autre que les clients Google.

    L’an­cien réseau XMPP de Google est encore là mais on ne sait pas pour combien de temps. Toujours est-il que les utili­sa­teurs vont migrer vers Hangout au fur et à mesure (consciem­ment ou non) et ce sont autant de gens qui devien­dront injoi­gnables pour ceux qui n’y sont pas encore. Pire : Il semble qu’ils sont encore vus comme connec­tés, mais ne peuvent pas lire vos messages ou vous en envoyer.

    Là aussi, le proto­cole n’est pas connu, donc il faudra avoir un logi­ciel spéci­fique pour Hangout, impos­sible d’uti­li­ser Pidgin ou un équi­valent.

    Sans avenir

    Twit­ter, MSN et Google s’en­ferment chacun dans leur pré : impos­sible de commu­niquer avec eux depuis l’ex­té­rieur, ou d’avoir une même appli­ca­tion qui se connecte aux diffé­rents réseaux. Diffi­cile de comp­ter sur Face­book pour s’ou­vrir, et les autres qui étaient au stade de déve­lop­pe­ment ou d’ex­pé­ri­men­ta­tion ne risquent pas d’in­ves­tir pour péren­ni­ser la chose désor­mais.

    Bref : Vous appar­te­nez au réseau que vous choi­sis­sez, et vous n’êtes qu’un pion dans la guerre qui oppose les multi­na­tio­nales d’In­ter­net. Le courant domi­nant est main­te­nant de fermer les fron­tières et de capi­ta­li­ser sur les utili­sa­teurs pieds et poings liés, c’est à dire vous. Votre proprié­taire pourra vous impo­ser les conte­nus, les services ou la publi­cité qu’il souhaite (rassu­rez-vous, il atten­dra un peu que ça se calme avant de le faire, histoire de ne pas risquer une migra­tion en masse). Une société souhaite lancer des conte­nus ou inno­ver ? OK si elle paye votre proprié­taire et n’entre pas en concur­rence avec lui. Moins vous pour­rez commu­niquer avec l’ex­té­rieur, mieux ce sera car vous serez sous contrôle de votre proprié­taire de réseau.

    Sauf renver­se­ment de situa­tion ou prise de conscience excep­tion­nelle des utili­sa­teurs :

    • Jabber est mort à court ou moyen terme, sauf pour quelques geeks et inter­nautes convain­cus
    • Vous ne pour­rez plus choi­sir vos appli­ca­tions, il faudra accep­ter les appli­ca­tions offi­cielles, en leur donnant les droits qu’elles demandent, en accep­tant publi­ci­tés, mises en avant ou marke­ting qu’elles choi­sissent
    • Si vous n’ac­cep­tez pas de vous lais­ser enfer­mer et menot­ter sur un seul réseau, il faudra instal­ler et lancer simul­ta­né­ment plusieurs logi­ciels diffé­rents non inter­opé­rables
    • Le web ouvert est mal barré

     

  • Ateliers sur la docu­men­ta­tion webperf

    J’ai partagé en ligne il y a quelques temps le début de livre que j’avais rédigé à propos de la perfor­mance des sites web.

    L’objec­tif était d’avoir une « bible » qui réfé­rence toutes les tech­niques impac­tant le temps de char­ge­ment des sites web et la théo­rie sous-jacente. Une moitié du travail était déjà là. C’est sur github, dans un format acces­sible à tous.

    En le posant sur github l’es­prit est « ce contenu appar­tient à ceux qui se l’ap­pro­prient ». Si vous y parti­ci­pez, ça devient un peu le vôtre. De mon côté ce n’est déjà plus « mon livre » mais un projet commu­nau­taire, dont je ne souhaite d’ailleurs pas forcé­ment être le main­te­neur ou l’ani­ma­teur.

    Pour initier la dyna­mique néces­saire, nous avons réalisé deux ateliers : un à Paris fin avril, un dans le cadre de Sudweb la semaine dernière. Il s’agit d’ex­pliquer le projet, puis de réali­ser relec­tures, mises à jour et rédac­tion par petits groupes. Le projet avance un peu, et chacun repart avec une meilleure connais­sance ou des échanges sur un sujet pointu.

    Si vous ne savez pas par où commen­cer vous pouvez commen­cer par regar­der les tickets en cours (« issues » dans la barre de menu github). Ils sont clas­sés par chapitre et par type d’ac­tion (relec­ture, mise à jour, contenu manquant, etc.). Le fichier « HELP.md » à la racine du projet contient aussi un guide de démar­rage avec quoi et comment sur diffé­rentes ques­tions que vous pour­riez vous poser. Vous pouvez aussi simple­ment vous signa­ler et poser vos ques­tions sur la liste de diffu­sion française : https://groups.google.com/group/perfor­mance-web?hl=fr

    La suite c’est de conti­nuer avec les ateliers. Il faut prévoir un anima­teur et proba­ble­ment au moins une personne qui a déjà lu le contenu et saura répondre aux ques­tions tech­niques webperf. Je compte en propo­ser quelques uns mais n’hé­si­tez pas à en orga­ni­ser vous-même dans vos commu­nau­tés locales. Avec un peu de temps se déga­ge­ront certai­ne­ment une ou deux personnes pour animer tout cela sur le long terme.

    Retour sur les deux ateliers précé­dents

    Sur les ateliers passés il y a eu un bon travail sur les relec­tures, qui s’est traduit via quelques correc­tions, quelques ajouts, mais aussi une bonne série de tickets qui permettent main­te­nant de struc­tu­rer et guider les bonnes volon­tés.

    Un gros merci à tous ceux qui ont parti­cipé.

    Deux points soule­vés :

    • En plus de la demie-heure de présen­ta­tion du projet et du fonc­tion­ne­ment, il faut prévoir des créneaux d’au moins une bonne heure, préfé­ra­ble­ment une heure et demie. En dessous on manque de temps pour amener un résul­tat concret.
    • La licence initiale était inuti­le­ment complexe de façon à garder la possi­bi­lité d’em­barquer un éditeur papier dans l’aven­ture. Suite aux diffé­rents retours, il appa­rait plus sage de rebas­cu­ler sur une licence ouverte plus simple, peut être une Crea­tive Commons. N’hé­si­tez pas à en discu­ter ici ou sur la liste de diffu­sion webperf

    Voilà, main­te­nant c’est à vous de jouer.

  • Mais que faire avec la fibre 1 Gb/s de Google ?

    L’au­teur de Slate explore la fibre Google à 1 Gb/s déployée au Kansas. Malgré une démons­tra­tion de confé­rence vidéo avec inter­ac­tion sur Google Maps en instan­tané, l’au­teur semble dépité de ne pas trou­ver de mieux que « ouvrir cinq vidéo 1080p sur Youtube » dans sa recherche de la killer app qui justi­fie­rait une tel débit.

    Il a un peu raison, d’au­tant que cinq vidéo 1080p Youtube c’est entre 20 et 40 Mb/s, donc passe tout à fait sur n’im­porte quelle connexion câblée ou fibre à partir de 50 Mb/s. Il a raison mais il passe tota­le­ment à côté de l’enjeu, et pas mal de commen­ta­teurs français sur twit­ter aussi.

    Que vais-je bien pouvoir faire ?

    Je pour­rai vous rappe­ler quelle est la bande passante pour un blu-ray 3D en 120 Hz, pour la TV 4K dont on commence à parler, pour avoir ça en multi points de vues, et pourquoi pas une fois dans le salon et une fois dans la chambre des enfants, en paral­lèle du backup et de tout le reste. Ok, ce n’est peut être pas acces­sible *aujourd’­hui* mais four­nir de tels services sur le réseau alors que seuls quelques chan­ceux dans une ville des USA peuvent s’en servir, ce serait large­ment préma­turé. Ne vous inquié­tez pas, le Gb/s il finira par être utilisé large­ment avant d’être la norme pour la majo­rité de la popu­la­tion.

    Il n’y a pas de killer app

    Malgré tout, parler de ça c’est tomber dans le même travers que le jour­na­liste de Slate :  Se poser la ques­tion de la killer app c’est se trom­per de débat. Il n’y a pas de killer app, et il n’y a pas à en avoir.

    Qui a besoin d’une killer app ? Dites, c’est quoi la killer app de la cocotte minute ? Celle du micro-onde ? C’est un peu plus long mais vous faites bien la même chose sans. C’est juste plus pratique. Des usages pour un meilleur débit on a déjà tous ceux d’aujourd’­hui : Regar­der plus faci­le­ment des vidéos qu’a­vant, en patien­tant moins qu’a­vant, en meilleure réso­lu­tion. Renon­cer moins faci­le­ment à télé­char­ger des fichiers lourds et attendre moins pour cela. Synchro­ni­ser de plus en plus de fichiers en ligne, et attendre moins souvent la fin de synchro­ni­sa­tion avant de débran­cher. Partage plus faci­le­ment des photos ou des vidéos avec des tiers, en nombre plus impor­tant et en meilleure qualité/taille, en atten­dant moins la fin de l’en­voi.

     

    La killer app c’est de réduire les attentes, élimi­ner les frus­tra­tions, et ouvrir les portes pour faire émer­ger autre chose ; pas forcé­ment faire quelque chose de nouveau et de révo­lu­tion­naire.

    Oui mais… 1 Gb/s… utile ?

    Je me rappelle l’époque où on se moquait des 8 et 20 Mb/s de l’ADSL les trou­vant super­flu. Je crois que Xavier Niel a déclaré il y a à peine quelques mois que la fibre à 100 Mb/s était globa­le­ment inutile. Rien d’éton­nant à ce que la même image appa­raisse avec le palier suivant;

    Aucun de ces usages ne *jus­ti­fie* 1 Gb/s, pas plus que le passage de 20 Mb/s au 100 Mb/s ne se justi­fie (si on oublie le débit montant), ou qu’une ADSL 20 Mb/s n’était à l’époque fonda­men­ta­le­ment meilleure qu’une 8 Mb/s, et que cette dernière n’était elle-même indis­pen­sable à l’époque de la tran­si­tion avec la 2 Mb/s ou la 512 Kb/s. Par contre je mets au défi ceux qui y seront passés d’en­vi­sa­ger reve­nir en arrière.

  • TLS par défaut

    Il ne fallait qu’une heure pour le faire mais je ne l’avais jamais inves­tie jusqu’à présent. C’est main­te­nant fait : Cet espace utilise une connexion HTTP sécu­ri­sée par défaut.

    Le lien HTTP non sécu­risé redi­rige direc­te­ment vers la partie sécu­ri­sée. Cette dernière envoie l’entête HSTS pour bloquer ce choix.

    Remon­tez-moi toute diffi­culté.

  • Paie­ment avec Mozilla

    Je ne sais quoi penser. Mozilla a sorti sa solu­tion de paie­ment. C’est une étape essen­tielle dans l’objec­tif de propo­ser une plate­forme appli­ca­tive complète concur­rente à l’App store d’Apple et au Google Play d’An­droid.

    Main­te­nant, on va me dire que je suis trop critique sur un projet nais­sant mais..

    Prix par palier

    Le prix par palier est une fausse bonne idée. C’est une galère à gérer si on veut vendre sur plusieurs plate­formes ou si on vend aussi hors ligne. Comment est-ce que je synchro­nise les prix ou justi­fie les diffé­rences ?

    Google et Apple le font, parce qu’ils veulent que tout passe par eux et se plie à leur struc­ture. Est-ce vrai­ment le modèle de Mozilla ?

    Comment fais-je pour revoir mon busi­ness plan tous les six mois ? Tous les six mois Mozilla va chan­ger les prix en euros pour tenir compte des conver­sions face au dollar (alors que mes coûts sont en euros et ne changent pas). Au final c’est ma marge qui va faire yoyo hors de mon contrôle, et ça c’est sacré­ment risqué.

    Pire, pour moi qui vend du livre numé­rique avec des prix fixés, je ne peux simple­ment pas léga­le­ment me confor­mer à cette grille. J’ai pour­tant dans les cartons une appli­ca­tion mobile full web qui cadre pour­tant parfai­te­ment avec la philo­so­phie du Market Place Mozilla : dommage.

    Plus éton­nant, pourquoi n’ai-je pas de palier au delà de 10€ ? Il y a bien des logi­ciels qui valent plus de ce montant. Ce n’est même pas rare dans l’App Store ou dans Google Play. Côté Chrome Web Store on a un palier 17 à 37€ et un maxi­mum de tran­sac­tion à 1000€. Il serait dommage que le Market Place Mozilla se limite aux petits jeux à 2$.

    Commis­sion de 30%

    Je ne peux pas non plus donner 30% en commis­sion. Désolé, même avec toute la bonne volonté du monde. Comme beau­coup de commerçants, 30% c’est parfois plus que la marge brute de mes ventes. Si je donne ça, je suis défi­ci­taire avant même d’im­pu­ter mes coûts.

    Oui, Google et Apple le font. Ils profitent de l’en­fer­me­ment de leurs utili­sa­teurs : Si vous voulez vendre il faut accep­ter de passer par là et de lais­ser 30%. Est-ce que vrai­ment Mozilla cherche aussi à moné­ti­ser l’en­fer­me­ment ?

    Mais quitte à compa­rer il faut parler du Chrome Web Store, qui est bien plus proche de l’ap­proche du Market Place Mozilla. Donc le Chrome Web Store prend 5%. Pas 30%, 5%. Forcé­ment, l’uti­li­sa­teur n’est ici pas dans un jardin fermé donc il est plus diffi­cile de justi­fier de telles commis­sions.

    D’ailleurs, quitte à en parler, Google Wallet est capé à 5% mais peut même prendre moins que ça si on dépasse les 9 € sur une tran­sac­tion. Il y a une API pour du in-app, et au final les mêmes possi­bi­li­tés de paie­ment puisque pour l’ins­tant Mozilla n’est bran­ché qu’à Google Wallet. Diffi­cile de justi­fier les 25 points supplé­men­taires de commis­sion.

    Alors ?

    Alors une API passe-plat qui fait la liai­son avec diffé­rents four­nis­seurs de solu­tions de paie­ment ça a de la valeur. Se simpli­fier la vie aussi.

    Disons qu’il faudrait au mini­mum faire sauter la contrainte du palier maxi­mum. Là je peux être prêt à payer un ou deux points de pour­cen­tage sur le prix de vente. Le pres­ta­taire pourra certai­ne­ment en gagner au moins deux autres avec ses pres­ta­taires de paie­ment vu le volume de tran­sac­tions en jeu et l’ab­sence d’in­te­rac­tion avec les vendeurs.

    Par contre pour 25 points de plus que Google Wallet, ça me parait diffi­cile à justi­fier. C’est encore plus plus diffi­cile à imagi­ner aujourd’­hui où ça ne fait que Google Wallet avec des contraintes en plus et moins de fonc­tion­na­li­tés.

  • 42 pour une seule école ? ça fait 41 de trop

    Bon, une nouvelle école. Quelques réac­tions :

    J’ap­pré­cie l’ou­ver­ture sans trop faire atten­tion à l’âge. Les forma­tions privées sont trop souvent atta­chées au cursus avec l’obli­ga­tion d’en­chaî­ner sans s’ar­rê­ter sous peine de devoir passer dans les forma­tions conti­nues spéci­fiques pour.

    J’ap­pré­cie aussi l’hon­nê­teté de faire une vraie sélec­tion, sur l’été pour lais­ser les élèves avoir une porte de sortie avec la fac. Le fait de croire dans une forma­tion de déve­lop­peur et pas que dans des chefs de projets / ingé­nieurs, ça me fait aussi plai­sir : Il faut recré­di­bi­li­ser ces postes si on veut avoir des gens compé­tents.

    Tech­ni­cien expert, C++

    On y forme des tech­ni­ciens, dans la pure lignée Epita / Epitech. Que ce soit un ancien Epitech qui reprenne la chose n’est pas anodin. Ce n’est ni un plus ni un moins, juste diffé­rent de beau­coup de forma­tions actuelles. Je conti­nue à voir une vraie diffé­rence entre ceux qui sont formés avec une orien­ta­tion « ingé­nieur » et ceux qui sont formés avec une orien­ta­tion « tech­ni­cien expert ».

    Une école de plus avec de réels tech­ni­ciens infor­ma­tiques très poin­tus, ok, pourquoi pas, voyons plus loin.

    On ne cède pas à la mode. Tout s’ap­prend par C++ dès la première année. C’est la langue obli­gée qui sert de base pour le reste si je lis bien le programme. Je dirais que ça ne fait pas de mal, que les déve­lop­peurs bas niveau sont trop peu nombreux, mais je ques­tionne la perti­nence de voir le modèle objet par le prisme de C++.

    Peu de web

    Par la suite il y a de nombreuses sections pour C# et les tech­no­lo­gies Micro­soft, quelques sections Java, mais pour le reste on repas­sera : 3 crédits pour apprendre toutes les tech­no­lo­gies web (Javas­cript, PHP, HTML, XML, etc.) et 3 autres pour apprendre en même temps les frame­works web et le e-commerce (Rails, Zend, Ruby, le e-commerce, les cms, les IHM web, et même l’er­go­no­mie web), ça fait fran­che­ment chiche, même pour un simple survol Si j’étais méchant je dirai qu’on comprend mieux le pourquoi des inter­faces de Free.

    Peut être est-ce parce que c’est mon domaine et que j’y attache de l’im­por­tance, mais le web me semble l’objet tech­no­lo­gique majeur de ces dernières années. Bref, pour moi c’est étrange d’y consa­crer si peu. Je ne vois pas les gens apprendre Javas­cript, PHP, HTML5, Zend Frame­work, Ruby et Rails comme ça d’un coup.

    Quelques points datés

    Je conti­nue à tiquer sur GANTT, UML, Merise, ITIL. Je peux le comprendre dans certaines forma­tions. J’ai plus de mal dans une nouvelle forma­tion de zéro, et surtout dans celle là qui est très orien­tée pratique / tech­nique / déve­lop­pe­ment.

    À l’in­verse, pour une forma­tion axée sur le projet et la mise en pratique, parler de méthodes agiles en dernière année ça me semble un peu du gâchis.

    Point global sur le programme

    Bon, mais fina­le­ment tout ce qui précède reste assez cohé­rent. On forme des tech­ni­ciens experts, plutôt bas niveau, dont le haut du panier saura proba­ble­ment inter­ve­nir partout avec aisance et compé­tence.

    Tout juste le programme laisse-t-il appa­raître beau­coup de noms de tech­no­lo­gies et j’au­rais aimé y voir plus d’al­go­rith­mie ou de théo­rie, mais il est tout à fait possible que ce soit abordé à l’oc­ca­sion des projets.

    Je ne vais pas dire que c’est ce que j’au­rais choisi en créant une forma­tion, mais ça ne me semble pas méri­ter toutes les critiques que j’ai vues.

    Enro­bage marke­ting

    Non, moi ce qui me fait prendre de la distance c’est l’en­ro­bage. Ça pue le mauvais marke­ting au point que ça en est néga­tif. J’ai l’im­pres­sion de retrou­ver l’EPITA en 97 : tutoie­ment, on met en avant la créa­tion de virus, une épreuve de sélec­tion « ultime et redou­table » (qui élimine 2/3 à 3/4 des candi­dats, donc bien moins que la plupart des concours ou proces­sus de sélec­tion, dans l’édu­ca­tif ou non), le but est plus d’en mettre plein les yeux que d’ap­pa­raître sérieux.

    On retrouve aussi cet enro­bage dans le super marke­ting « pas de diplôme, l’im­por­tant ce sont les compé­tences ». Sauf que le diplôme en France c’est essen­tiel­le­ment un certi­fi­cat indiquant que tu as suivi une certaine forma­tion. Au lieu d’in­diquer « diplôme de master à xxxx » les élèves indique­ront « suivi forma­tion complète à xxx ». S’ils ne le font pas c’est mauvais signe pour la répu­ta­tion de la forma­tion en ques­tion.

    Pas de diplôme

    Au final ça ne chan­gera donc rien. Ou plutôt si, ça rendra impos­sible certains emplois publics ou diffi­cile certaines embauches à l’étran­ger, ça sera irréa­liste d’en­chaî­ner sur d’autres études supé­rieures comme la recherche ou un MBA en gestion/commerce pour la double compé­tence, et ça empê­chera les échanges par équi­va­lence de diplôme/compé­tence en Europe.

    Je note d’ailleurs que le parcours du DG[*] avec un MBA à HEC ne peut proba­ble­ment pas être fait dans cette nouvelle école (sauf à reprendre de zéro la prépa HEC) juste­ment à cause du manque de diplôme. Faites ce que je dis, pas ce que je fais. Tout ça pour quoi, un effet de manche marke­ting ?

    En fait là aussi ça me fait beau­coup penser à l’EPITA qui à l’époque se défen­dait de trou­ver un inté­rêt à avoir un diplôme reconnu par la CTI mais qui tentait régu­liè­re­ment de la demande (et se fera reje­ter jusqu’en 2007).

    Je me dis que l’ab­sence de diplôme en sortie est proba­ble­ment dû à l’ab­sence de pré-requis du bac en entrée (ça empêche proba­ble­ment de faire recon­naître le niveau ensuite par l’État) mais ça aurait été plus honnête de l’ex­pri­mer ainsi.

    [*] D’ailleurs, c’est moi ou il y a un couac ? Dans son profil Linke­din le DG en ques­tion est ingé­nieur EPITA depuis 92 alors que cette dernière ne délivre de diplôme reconnu que depuis 2007. Même chose pour la préci­sion du master EPITECH 2005 alors que l’école n’est habi­li­tée que depuis 2007. Pire, parce que là il indique une forma­tion entre 1999 et 2005 alors qu’il a fondé l’école et en était le DG à ce moment là (ça me parait un peu incom­pa­tible avec l’idée d’en sortir diplômé pour moi). On voit qu’ef­fec­ti­ve­ment tout n’est pas clair côté diplômes, et ça n’ins­pire pas confiance (Je me souviens un peu trop de l’am­bi­guité entre­te­nue concer­nant le titre ingé­nieur à l’EPITA avant qu’ils n’ob­tiennent l’ha­bi­li­ta­tion).

    Forma­tion

    Je retrouve encore EPITA dans l’idée qu’ils forment des archi­tectes tech­niques, des chefs de projets et des experts. J’ai bien parlé de tech­ni­cien expert plus haut, mais c’est plus pour faire la diffé­rence avec nombre de forma­tions de tech­ni­ciens basiques. Il reste que faire miroi­ter qu’être archi­tecte ou expert en sortie d’école c’est trom­per les élèves. À mon époque certains EPITA croyaient valoir deux fois le salaire d’em­bauche moyen telle­ment on leur montait la tête à ce niveau (je parle d’EPITA mais ce n’étaient pas les seuls).

    Et là où je bip c’est quand je vois parler d’école peer-to-peer. Outre le mot clef marke­ting pour les élèves en manque, ça me rappelle ce que j’ai vu dans d’autres orga­nismes de forma­tion où ce sont les élèves qui donnent les cours aux autres élèves. Ça peut fonc­tion­ner, mais ça a aussi de graves manques. C’est aussi juste infai­sable au départ.

    Si on ajoute que monter une promo de 1000 élèves en une seule année est quasi­ment infai­sable en arri­vant à une bonne qualité de forma­tion, j’ai tendance à croire que les cinq premières promo passe­ront à la trappe et qu’on s’en moque.

    Epita / Epitech / 42

    Au final voilà juste une EPITA / EPITECH de plus, fondée par la même personne, avec la même orien­ta­tion de tech­ni­cien expert, la même philo­so­phie vis à vis des diplôme (affir­mer que c’est inutile jusqu’à enfin réus­sir à avoir l’ha­bi­li­ta­tion), le même danger sur la forma­tion en partie assu­rée par les élèves. Faire des écoles en série ne m’ins­pire pas tant confiance que ça. La forma­tion n’est cepen­dant pas aussi critiquable que ne le laissent entendre quelques geeks.

    Côté résul­tat, comme les EPITA / EPITECH, il peut en sortir du mauvais comme du bon. Et comme dans les deux autres, il en sortira proba­ble­ment quelques-uns de très bons, comme une masse qui n’est pas excep­tion­nelle pour autant. Bref, comme partout : La valeur des gens dépend plus des gens que de la forma­tion.

    Vus le système, la promo immense et le côté marke­ting un peu forcé, je conseille tout de même au moins de ne pas faire partie des premières promos qui risquent de payer les pots cassés.

  • Graphiques à affi­cher – Flotr2

    Il y a long­temps j’uti­li­sais jpgraph puis arti­chow en PHP pour géné­rer toutes sortes de courbes ou camem­berts. Un peu après j’uti­li­sais beau­coup les API google chart, avec pour bonne valeur ajou­tée de ne plus faire de trai­te­ment sur mes serveurs. Le anno­ta­ted time­line est d’ailleurs encore un modèle du genre avec ses anno­ta­tions et ses possi­bi­li­tés de zoom par période.

    J’ai testé plusieurs biblio­thèques javas­cript plus ou moins inté­res­santes mais je suis retombé sur Flotr2 qui génère des images assez lèchées. Pour de l’ap­pli­ca­tif complexe les fonc­tion­na­li­tés de google chart restent avec peu d’équi­valent, mais pour 80% des besoins courants, ça fait le job, et plutôt très bien.

    Vous avez quoi en stock de votre côté pour géné­rer des info­gra­phies de données ?

  • Défi­nir son API : version­ne­ment

    Toujours dans la logique de réflé­chir son API, parce qu’un jour il faudra la faire évoluer, comment gérer le version­ne­ment ?

    Plusieurs solu­tions ont émergé :

    • https://api-v2.example.com/mares­source
    • https://api.example.com/v2/mares­source
    • https://api.example.com/mares­source-v2
    • https://api.example.com/mares­source?v=2
    • https://api.example.com/mares­source avec une entête Version: 2
    • https://api.example.com/mares­source avec une entête Accept ou/et Content-type: appli­ca­tion/monfor­mat;version=2

    La solu­tion du sous-domaine n’est à mon sens à réser­ver que pour les big-bang. Elle n’est pas faci­le­ment multi­pliable à l’in­fini, mais à l’avan­tage de permettre aisé­ment d’avoir même deux plate­formes tota­le­ment sépa­rées pour les deux versions de l’API.

    Les deux suivantes se distinguent par le fait de version­ner l’API ou la ressource. J’ai tendance à penser que s’il faut version­ner la ressource en cassant la compa­ti­bi­lité, alors c’est peut être une nouvelle version de l’API qui est à publier si on ne veut pas finir avec un gros patch­work diffi­cile à main­te­nir : En gardant tout sous le même espace on s’in­ter­dit de faci­le­ment rendre obso­lète les anciennes versions.

    Quitte à parfois devoir version­ner au niveau de la ressource, l’idée d’ajou­ter un para­mètre a fini par me sembler plus propre. Il s’agit quasi­ment toujours de s’adres­ser à une repré­sen­ta­tion diffé­rente de la ressource, pas de chan­ger son sens fonda­men­tal. Le risque est que la plupart des gens conti­nuent à utili­ser la version d’ori­gine et ne pas prendre en compte le para­mètre. Rendre obso­lète des anciennes repré­sen­ta­tions risque là aussi d’être diffi­cile.

    Les possi­bi­li­tés d’ajou­ter les versions dans les entêtes sont souvent conseillées d’un point de vue théo­rique. En pratique mon retour est que c’est complexe à utili­ser, et d’une valeur ajou­tée assez discu­table. On oublie trop faci­le­ment que le bon usage de l’API tient direc­te­ment à sa simpli­cité et sa bonne compré­hen­sion. S’il y a besoin d’être expert en archi­tec­ture web pour comprendre le pourquoi des choses, c’est une mauvaise solu­tion. Le « tout dans l’URL » ajoute une faci­lité pour tester et échan­ger entre tech­ni­ciens qui vaut toutes les posi­tions acadé­miques du monde.

    Twilio a aussi une façon inté­res­sante de gérer les versions. Au lieu d’un v2 ou v3, le déve­lop­peur indique une date et c’est le serveur qui sélec­tionne la version de l’API à utili­ser en fonc­tion de la date. C’est tentant, souple, mais j’ai peur que ce ne soit pas suffi­sam­ment expli­cite sur ce qu’on utilise ou sur comment gérer ce para­mètre. Qu’est-ce qui change si je met à jour la date ?

    Des lectures et expé­riences je tire quelques recom­man­da­tions :

    • Prévoir dès le départ un système de version­ne­ment, vous en aurez besoin un jour, ne croyez pas que vos API pour­ront rester telles quelles ad vitam eter­nam
    • Impo­ser un version­ne­ment expli­cite, immé­dia­te­ment, dès la première version. Vous évite­rez les ambi­guï­tés et une partie des moules qui s’at­tachent aux adresses « sans version » par défaut
    • N’uti­li­ser que des numé­ros de version simples, pas de notion de mineur/majeur, pas de points ou virgules : Si ça change de façon non compa­tible c’est une nouvelle version et on incré­mente d’une unité. Le reste c’est du marke­ting et ça n’a rien à faire dans vos URLs.
    • Utili­ser un version­ne­ment dans l’URL, à la racine du service ; il sera temps d’uti­li­ser un autre sous-domaine si un jour il y a un vrai big bang qui le néces­site
    • Docu­men­ter (oui, c’est évident, mais pas si simple à ne pas oublier)
  • Défi­nir son API : authen­ti­fi­ca­tion

    Je lis le PDF gratuit de Apigee à propos du design des API web. Si les autres PDF gratuits du site sont assez creux, celui là pose de bonnes ques­tions qui font écho avec mes propres reflexions.

    Je le prends dans le désordre et pour reprendre mes erreurs passées ou celles que j’ai vu chez les autres :

    • Pas de système de session avec point d’en­trée spéci­fique pour le login. Ça demande au client de se préoc­cu­per de l’ex­pi­ra­tion de la session et de son main­tient. Pour des appels isolés ça veut dire faire deux requêtes (login + action) au lieu d’une, avec un délai de réponse finale allongé et une charge plus impor­tante pour le serveur. Sauf besoin spéci­fique, il faut rester en state­less : Chaque connexion contient ses propres infor­ma­tions d’au­then­ti­fi­ca­tion.
    • Pas d’au­then­ti­fi­ca­tion par IP, comme je le vois trop souvent. Outre que c’est un poten­tiel problème de sécu­rité, c’est juste quelque chose de diffi­ci­le­ment main­te­nable et c’est toujours au dernier moment quand on veut faire un correc­tif, une migra­tion ou une bascule vers le serveur de secours en urgence qu’on se rend compte du problème.
    • L’au­then­ti­fi­ca­tion HTTP Digest me semble être une mauvaise réponse à tous les problèmes. Pour amélio­rer légè­re­ment la résis­tance aux inter­cep­tions, il faut stocker le mot de passe en clair côté serveur. Une authen­ti­fi­ca­tion HTTP Basic avec du TLS pour sécu­ri­ser la commu­ni­ca­tion me semble bien plus perti­nent, et aussi plus simple à réali­ser.
    • Le système fait maison est toujours la pire solu­tion, même si vous pensez savoir ce que vous faites. C’est un NO GO commun à toute problé­ma­tique qui touche la sécu­rité. Vous avez plus de chances de vous tirer une balle dans le pied qu’autre chose, et pour le même prix ce sera toujours plus complexe quand vous commu­nique­rez avec des tiers.
    • OAuth 2 a la mauvaise idée d’être plus une boite à outils qu’une solu­tion finie. Même les gros groupes se prennent les pieds dans le tapis avec ça. On rejoint un peu le système fait maison. OAuth a ses défauts, mais globa­le­ment est une sphère contrô­lée que vous devriez préfé­rer.

    Au final il reste le choix entre l’au­then­ti­fi­ca­tion HTTP Basic, l’au­then­ti­fi­ca­tion par certi­fi­cat client avec SSL/TLS, ou OAuth 1.0. Ma grille de choix est la suivante :

    • OAuth s’il s’agit d’avoir une authen­ti­fi­ca­tion à trois pattes. Hors de ques­tion d’im­po­ser à l’uti­li­sa­teur final de saisir ses mots de passes dans un logi­ciel tiers. Pour une API qui veut créer un écosys­tème de logi­ciels clients (type twit­ter) c’est le choix quasi­ment imposé. Oui il y a des diffi­cul­tés pour le mobile ou pour ce qui n’est pas « navi­ga­teur », mais ces ques­tions sont désor­mais large­ment docu­men­tées. Pensez bien que choi­sir ce type d’au­then­ti­fi­ca­tion demande un réel travail (par exemple trou­ver l’er­go­no­mie pour permettre à l’uti­li­sa­teur d’au­to­ri­ser et reti­rer l’au­to­ri­sa­tion d’ap­pli­ca­tions tierces sur votre propre système)
    • HTTP Basic par défaut pour quasi­ment toutes les autres situa­tions. C’est simple côté client, simple et maitrisé côté serveur, supporté partout et pour tout, suffi­sam­ment sécu­risé si on passe par du SSL/TLS.
    • Et les certi­fi­cats clients avec SSL/TLS ? C’est une solu­tion qui semble plus inté­res­sante que l’au­then­ti­fi­ca­tion HTTP mais qui se révèle complexe pour pas mal d’in­ter­lo­cu­teurs. La valeur ajou­tée ne semble pas valoir la complexité supplé­men­taire si vous n’in­te­ra­gis­sez pas avec des entre­prises de taille signi­fi­ca­tive. J’y croyais beau­coup, mais fina­le­ment j’ai peu d’ar­gu­ment face à la simpli­cité du HTTP Basic.

    Et vous ? vous utili­sez quoi pour l’au­then­ti­fi­ca­tion de vos services ?