 Avant de penser, j'aimerais juste par curiosité pure, savoir qui parmi vous entendu parlait d'HTTP2. C'est pas mal. J'espère que j'avoir des choses à dire quand même. Enfin, à vous apprendre. L'idée, c'est que c'est un sujet qui est en train de devenir d'actualité et l'idée c'est d'essayer de revenir sur People & Notions. Qu'est-ce que c'est ? Comment ça marche et comment on profiter ? Avant de rentrer dans l'idée du sujet, je vais passer par redéfinir un petit peu ce que c'est qu'HTTP, parce que pour être tout à fait honnête, avant de préparer la presse, on aurait demandé de définir clairement ou de parler d'HTTP. J'aurais été un petit peu embêté. Je pense que j'ai eu la même tête à peu près que ce sympathique monsieur à l'écran. En revanche, si j'avais eu la chance d'avoir un joker coup de fil, je pense que je vous rappelais ce monsieur-là. Parce que lui, je sais que c'est le papa du web moderne et qu'il a été directement impliqué dans la création d'HTTP et du World Wide Web. Et donc peut-être qu'il aurait commencé par nous raconter l'histoire du web. Alors pour ceux qui connaissent sa parcoeur, je suis désolé, je vais essayer de ne pas être trop long, mais ça commence en 1969 avec ARPANET. ARPANET c'est le premier réseau entre des ordinateurs avec des transferts de paquets. Ça a été créé par la DARPA, l'agence pour les projets de recherche de défense avancée aux États-Unis évidemment. Et les ordinateurs, il faut savoir, à l'époque, c'était des tubes électroniques. C'était pas des processeurs extra-comment qu'on connaît aujourd'hui. Il y avait des trucs plus modernes, mais c'était pas très intéressant comme projet, donc on a mis les fonds de tiroirs. Et la légende que c'était pour la résilience du réseau, que ce réseau puisse permettre à piloter des frappes stratégiques si jamais il y avait une catastrophe nucléaire aux États-Unis. On était en pleine guerre froide. C'est une légende, c'était vraiment pas ça du tout le principe et l'objectif du réseau à la base. Toujours est-il que ce réseau commence comme ça. Premier noeud, ça va être UCLA et Stoneford. Il y a peu d'hologie nucléaire là-bas. Et très vite, ça se développe, ça vient de l'Europe. On adopte TCPIP et en 90, on revient à la sortie de Bernard Li. Il travaille au CERN, à l'agence européenne pour la recherche nucléaire, beaucoup de nucléaire. Et donc, il y a une idée complètement sobrenue qui est si on se servait de ce réseau pour afficher des contenus qui sont lisibles par des humains. Donc ça, c'est vraiment étrange comme il est. Et il va encore plus loin, il va dire, est-ce qu'il y a des liens dans ces contenus qui permettent d'accéder à d'autres contenus sur le réseau. Donc ça, c'est la notion même d'hypertexte et d'hyperlien qui avait été formalisé bien avant dans la littérature, etc. Et c'est la naissance en 91 du projet World World Web qui va aboutir en 95 à la première version d'HTDP. Donc, pour revenir à notre sujet, qu'est-ce que c'est ? C'est un protocole client-server. Le client, c'est votre browser. Il envoie une requête à un serveur et le serveur, il répond avec du HTML et il vous balance des images de chatons. C'est simple, en vrai. Quand on regarde le détail, c'est moins simple. Mais bon, c'est pas très, très compliqué. Non plus, vous avez la requête en dessous. Vous avez donc le header de la réponse et en dessous, vous avez le contenu de la réponse. Ça, c'est l'HTML que vous voyez dans la console. Quand vous regardez une page web et que vous ouvrez la console. Alors, pourquoi Http2 ? En fait, ce qui est assez surprenant, c'est qu'entre le moment où il y a eu l'idée de World World Web et la dernière version d'HTDP, celle qu'on utilise encore aujourd'hui, il y a un point. Mais il s'est passé moins de temps entre ces deux moments-là qu'entre la version d'HTDP 1.1 et aujourd'hui. Alors du coup, il y a une start-up qui n'était pas contente, parce que son chiffre d'affaires est à peu près proportionnel au nombre d'images de chatons que vous regardez tous les jours. Elles s'appellent Google et puis ils se sont dit, non, mais nous, on veut que ça y est plus vite. On veut que vous regardiez plus de chatons. Et on va créer Speedy. Speedy, c'est un protocole alternatif. Donc avec un objectif comme son nom l'indique, c'est la vitesse, c'est la performance. En 2012, il y a l'Internet Engineering Task Force, c'est très militaire encore, qui va dire officiellement qu'ils vont se reposer sur Speedy pour créer la nouvelle version d'HTDP. Et en mai dernier, en 2015, Http2 est enfin annoncé officiellement, release officielle. Donc, on parle de vitesse, mais comment ça se fait qu'Http2 se soit plus rapide ? Qu'est-ce qu'il y a sous le capot exactement ? Eh bien, il y a trois optimisations majeures. La première, ça concerne les tailles de requêtes. En fait, aujourd'hui, ce n'était pas le cas à l'époque, mais aujourd'hui, une page web, c'est assez courant qu'il y ait une centaine de ressources à télécharger. Une centaine de ressources à télécharger, ça fait beaucoup de haideurs et avec beaucoup de redondance entre ces haideurs. Donc, on a créé un algorithme de compression qui s'appelle HPEC et qui va permettre de concresser tout simplement tous ces haideurs. Et avec d'autres avantages, ça va limiter les randoms avec le serveur. On passe aussi de textuels abinaires, ça va permettre des traitements plus efficaces, plus rapides par les proxies, etc. Donc, ça, c'est la première optimisation un petit peu technique. La deuxième est assez sexy. C'est ce qu'on appelle le multiplexing. Alors, il faut savoir qu'on a acheté l'Http1.1 Dans une connexion TCP, on va pouvoir mettre une requête et une réponse. Donc, du coup, ça fonctionne comment ? On ouvre une connexion TCP, on envoie une requête, on attend la réponse, on ferme la connexion, on fait la suivante. Donc, on travaille en série. Ce n'est pas idéal. Surtout qu'il y a des temps de négociations pour chaque connexion TCP qui se cumulent en fonction avec les ressources. Donc, l'idée, là, ça va être de se dire, on va ouvrir une connexion TCP, on va la garder ouverte. Et puis, on va permettre aux clients, donc, votre browser de faire plein de requêtes et aux serveurs de répondre à ces requêtes dans toujours la même connexion TCP et même dans le désordre, ça évite le phénomène de head of line blocking. C'est-à-dire qu'on a acheté l'Http1. S'il y avait une ressource qui m'était beaucoup trop de temps à arriver, ça bloquait toute la file d'attente derrière. Ce n'est pas sympa. Alors que, là, vu que ça se fait en parallèle, ce n'est pas grave, ce sera la dernière ressource à être téléchargée, mais on a tendance de télécharger les ressources qui fonctionnent bien. Donc, ça, c'est assez sympa. Et puis, la dernière optimisation, et là, on n'est plus dans le sympa, c'est dans le domaine de la magie, c'est-à-dire, le serveur, il sait très bien quelles sont les ressources qui sont nécessaires pour afficher ma page. Donc, dès, j'envoie ma première requête et lui, il balance toutes les ressources d'un coup. Donc, j'ai direct RoyalObar, j'ai tout ce qu'il me faut pour afficher la page. Alors, je ne sais pas si je suis très clair. Donc, j'ai fait des schémas. En général, ça marche pas mal. Donc, vous aurez compris, ici, Http classique. Alors, si on veut rentrer dans le détail, en vrai, en Http1.1, il y avait ce qu'on appelle du pipelining qui permettait d'envoyer plusieurs requêtes au sein d'une même connexion TCP, mais il fallait répondre dans l'ordre. Et en plus de ça, il n'y avait aucun invéquateur compatible. Donc, bon, bref, c'est vraiment une parenthèse. Donc, du coup, ça se passait comme ça. Http2 avec du multiplexing, on voit que dans une même requête TCP, on met plusieurs requêtes et le serveur répond dans les ordres. Et avec le serveur push, on n'a qu'une seule requête et puis ça balance. Bon, s'il faut vraiment insister sur le comprendre les avantages de ça, je vous invite à vous projeter dans un café. Et donc, Http1, vous vous arrivez, vous voulez commander cinq plats, vous vous posez, il y a le serveur qui arrive, vous commencez le premier, vous attendez qu'il revienne, vous commandez le deuxième, vous attendez qu'il revienne et ainsi de suite. Http2, vous rentrez dans le café, vous posez, le mec, il sait déjà ce que vous voulez commander et vous apporte tout sur un plateau. Voilà. Donc, personnellement, j'ai plutôt hâte que les cafés parisiens passent en Http2. Alors, est-ce que ça marche ? C'est une question qui est légitime, parce que là, c'est très théorique. Première chose à savoir, c'est que tous les navigateurs modernes sont compatibles aujourd'hui. Plutôt cool. Normalement, ça devrait marcher. Et on a déjà posé la question, oui, c'est rétro-compatible, évidemment. Si le navigateur n'est pas compatible, c'est peut-être une page cassée. Ça aurait été con. Quand on fait le boulot bien, donc les mecs ont bien bossé, c'est pas magique. Quand on fait le boulot bien, voilà, on passe de un schéma waterfall classique, comme ça, qui met pas mal de temps à cette espèce de monstres qui balance tout et qui est hyper rapide. Donc, dans l'absolu, oui, ça marche. Ça marche très, très bien. Et pourtant, pourtant, il y a que 6% décident dans le monde qui profitent de ces optimisations. Donc, il y a de la rume pour profiter de ça par rapport à vos petits camarades. Alors, comment on peut profiter d'acheter les P2 ? Premier truc à faire, c'est passer en SSL. Alors, sur le papier, acheter P2, il nécessite pas le SSL. Mais dans les faits, c'est toujours compliqué un petit peu, dans ces histoires. Dans les faits, il n'y a aucun browser qui va permettre de faire du HTTP2 si vous n'êtes pas en SSL. Donc, dans les faits, il faut passer en SSL. De toute façon, c'est meilleur pour le référencement ou ce que Google l'a mis dans les algos. C'est meilleur pour la privauté des données, tout ça. Et en plus de ça, LED Syncrypt maintenant donne des certificats gratuits. Donc, il n'y a plus d'excuse de passer en SSL. Deuxième point, et ça devrait vous faire plaisir, il faut moins travailler. Qu'est-ce que j'entends par là ? Il y a pas mal des optimisations qu'on s'acharnait à faire pour gagner quelques millisecondes en HTTP1 qui ne servent plus à rien ou même qui sont contre-productifs en HTTP2. Alors, par exemple le Spriting. Le Spriting, c'est vous savez quand vous avez plein de petites images et vous les concaténez dans une grosse image et puis vous affichez la partie que vous aimez bien, enfin, vous voulez afficher, pas que vous aimez bien, avec du positionnement CSS. Donc ça, ça se fait pas mal. Ça, ça fait plus aucun sens. C'est beaucoup plus rapide de télécharger 30 images en parallèle, petites images en parallèle que de télécharger un gros fichier en HTTP2. Ça fait... Donc ça, c'est... On oublie, on arrête ça. C'est plus simple en plus, c'est mieux. Concaté-nation, mettre tous ces fichiers GES dans un gros blob ou tous ces fichiers CSS dans un gros blob, on arrête aussi. C'est exactement le même principe. Il vaut mieux faire du téléchargement parallèle de petits fichiers que de faire des gros fichiers. Le sharding, c'est le fait de disperser si les ressources nécessaires à la page sur différents domaines, coups qui laissent de préférence pour pouvoir justement paralyser les télécharges dans des ressources et avec des meilleures connexions parce que justement, c'est cool qu'ils laissent, etc. Encore une fois, avec le multiplexing, etc. Ça fait plus de sens. Si on est sur des domaines de différence, c'est-à-dire qu'il y a des temps de négociation pour chaque domaine au niveau des connexions TCP, il vaut mieux en avoir qu'un seul sur son serveur et qui paralysait dans la même connexion TCP. Donc on oublie aussi. Donc c'est cool, il faut rester simple et ça marche. Le dernier point dont j'ai parlé, je suis un peu embêté parce que je n'ai pas de réponses mais c'est vraiment très, très clair. En PCDN, en gros, c'est pour gagner en vitesses, évidemment. Et quand ça marche, il y a pas mal d'optimisation qui pratique, mais globalement, ils vont essayer de mettre les ressources plus proches de vous d'un point de vue distance géographique pour éviter la latence dû à aller chercher chaque ressource loin. Seulement, sur le papier, ça marche très bien. Il y a nos amis de The Thames Foundry, donc la boutique de The Thames qui est passée, alors c'était à l'époque de Speedy, donc les mecs qui sont à jour. Ils ont passé leur site sur Speedy. Ils ont fait un test. Ils ont dit, on va faire un test à l'autre bout du monde. Donc en Australie, il y avait un de leurs employés qui bossait là-bas. Et il a fait des requêtes. Ils ont analysé les téléchargements de ressources. Donc ça, c'est avec CDN. On est plutôt sur un schéma de Waterfall classique avec des tentes de négociation en SSL qui sont assez lents. Et donc, on est là-dessus. 2,3 secondes de téléchargements de page. C'est déjà pas dégueu, mais bon, c'est. Voilà, sans CDN, on est en Australie, ils requêtent les US. Donc les mecs, ils font 22% plus vite. C'est pas logique. On a mis un CDN, ça devrait aller plus vite. Donc sur le papier, c'est assez normal. C'est-à-dire que ce qui coûte cher, en vrai, quand on est en STP2, c'est le temps de la première connexion. Donc, allez faire la première connexion à son serveur, et ensuite faire une deuxième première connexion à un CDN distant. En fait, l'avantage, il est perdu par rapport à l'avantage qu'on gagne sur la latence de la distance. Cependant, le benchmark pourrait être très clair. Il n'a pas été fait dans des conditions ultra scientifiques. Ça date un petit peu. Donc, il y a des CDN maintenant qui sont passées en STP2. Je ne pense pas que les CDN étaient STP2 à l'époque. Donc, bref, pour les CDN, je pense qu'il y a encore du travail à faire. En d'ailleurs, on compte bien de notre côté faire des benchmarks et on les partagera au temps possible et pour l'instant, donc, je ne sais pas. Pour résumer tout ça, donc, c'est plutôt simple de passer en STP2 et d'avoir un site super rapide. Il faut passer en SSL, arrêter les optimisations qui ne servent à rien et trouver un hébergeur compatible, simplement. Je ne sais pas si je fais en avance ou en retard. Donc, très bien. OK, super. Donc, merci. Et si vous avez des questions, bien évidemment. Bonjour. Bonjour. Comment fonctionne le push pour les hébergeurs, justement? Comment il détermine toutes les ressources en analysant les différents codes ou sur les applications complexes? Comment ça peut fonctionner aussi? Pardon, je ne vous vois pas. Par contre, je n'ai pas vu. C'est une très bonne question. C'est pour ça que je n'avais pas trop parlé dans la presse parce que la partie server push, c'est la partie qui est la plus expérimentale, on va dire. Ce n'est pas encore quelque chose qui est bien géré. Donc, il y a au niveau des header HTTP. Pas des header HTML. Des header HTTP pour passer REL égal préload qui va permettre de d'indiquer qu'il faut se charger ses ressources pour cette requête. Donc aujourd'hui, alors, ce n'est pas automatique. Il y a de la dernière version du doc, je crois qu'elle date de janvier. Donc il y a quelques semaines. Donc, c'est vraiment quelque chose qui n'est pas encore standard. Et donc, c'est quelque chose qui va se tasser. On va dire d'ici, je pense, quelques semaines. Il y a des gens comme chez H2O, je crois qu'ils ont des outils avec Casper qui essaient d'automatiser. Ça me semble utile. Mais voilà, aujourd'hui, il n'y a pas de... A priori, vous n'avez rien à faire. Il faut juste attendre que le truc soit généralisé. Bonjour. Je me posais la question, parce que ça a l'air super intéressant, là. Ça a l'air super intéressant. Ça va vachement plus vite. Le problème, c'est que je travaille souvent avec des clients en Afrique qui ont une très mauvaise bande passante. Télécharger sans fichier en même temps par rapport à un téléchargement séquentiel. Je ne vois pas trop l'intérêt puisque ça ne marchera pas chez un client qui a une mauvaise bande passante. Alors, ça marchera moins. On est d'accord que, plus petit ou moins, ça va passer vite. En revanche, on va toujours gagner sur tous les temps de connexion TCP successifs qu'on obligait de faire si on est en HTP1. Donc dans l'absolu, il n'y a pas de raison. Même si la bande passante est plus faible, de toute façon, ça sera plus rapide à priori. Je testerai. Merci. Avec plaisir, je veux bien les résultats des tests. Bonjour. Oui, donc je suis aussi directeur technique chez groupe Jeune Afrique. Donc j'ai aussi les mêmes problématiques. Et j'en ai en plus, en fait. Donc tout d'abord, je pense que déjà, c'est une bonne technologie. Malheureusement, quand vous avez dit il faut installer un scientifique KSSL, en fait, sur sa machine. Et c'est là le problème, en fait, parce que nous, on a un serveur Varnish, donc vous devez bien connaître, je pense. Et vous avez oublié ces petits détails là, c'est quand on a des serveurs applicatifs entre le client et le serveur. Typiquement, Varnish ne gère pas, n'a pas implémenté le SSL. Et en fait, paralyser une requête, ok, c'est, enfin dans la théorie, c'est plus pratique. Mais si j'arrive mon serveur Varnish, parce qu'il ne sait pas le gérer, en fait, je vais perdre en temps de connexion. Alors, par exemple, Lollefair, maintenant, gère le HTTP2. Donc finalement, on n'a plus les problèmes que vous avez montrés, mais on a toujours le Varnish. Donc je ne peux pas me permettre de supprimer un Varnish et ne plus avoir de cache de reverse proxy, en fait. Donc, est-ce que déjà, vous avez eu ce qu'a figure l'oeuvre chez Tim Claude et si vous avez eu, est-ce que vous l'avez résolu ? En fait, sur Internet, on voit que les gens mettent un engines, en fait, en proxy, passent devant. Et je ne trouve pas que ça soit forcément amélioré de manière. Et c'est même, ça rajoute une couche de maintenance entre les deux. Est-ce que vous avez une réponse ou on peut aller dessus ? Pas franchement. Ce que je peux dire, c'est qu'on n'utilise pas Varnish. Donc on n'a pas été confrontés aux problèmes. Du coup, non, j'ai pas vraiment de réponse. Par contre, d'ailleurs, n'hésitez pas à me faire un mail et puis on ne résistera pas avec plaisir pour en discuter. Je pourrai voir ça avec notre CTO qui sera plus d'un mème de vous donner une réponse. En fait, c'est merci. J'ai deux petites questions. Justement, par rapport à ça, est-ce que ça change vis-à-vis des navigateurs ? Vous savez que, normalement, il y a toujours la problématique avec les points d'interrogation dans les URL où, en fait, le navigateur veut forcer absolument de ne pas le mettre en cache et des choses comme ça. Est-ce que l'HTTP2 va justement modifier ce comportement ou pas du tout ? Alors, au niveau des URL, il n'y a pas d'un point d'interrogation ? Oui, c'est-à-dire, par exemple, si on appelle un fichier CSS et qu'on met un point d'interrogation version égal 2, le navigateur va dire, ok, toi tu ne veux pas de cache, je ne t'en mets pas. Et du coup, c'est assez pénible parce que justement, on est oublié, concernant WordPress, de faire justement tout un jeu de hook pour enlever tous ces versions-là. Et donc du coup, on se desserre nous-mêmes à chaque fois dans ce système, quoi. Ok, alors... Ce que je sais, c'est que, en tout cas, sur la partie serveur push, des gens qui ont fait des tests et qui étaient en vétée, parce que justement, à partir du moment où on pousse toutes les ressources qui sont nécessaires, donc CSS, etc., à chaque fois qu'on fait une requête, en fait, du coup, on ne se sert plus du cache. Donc ça, c'est un peu gênant pour les gens qui ont expérimenté le serveur push de façon un petit peu artisanale, en ce qui concerne la problématique des URL. Je serai paré, Bromble. Et la deuxième question, plutôt simple, il me sent, un jouet juste confirmé, que l'HTTP2, justement, libère cette notion de quatre téléchargements parallèles. Ouais. Ok. Et donc là, c'est illimité, alors ? Oui, alors... illimité peut-être pas, mais on va dire sur le papier, ouais. Moi, enfin, si vous voulez. Ok. Merci. Bonjour. Gros merci pour la présentation, déjà. Chez nous, chez les Belges, on est passé hier en HTTP2 dans notre boîte. Et on a fait quelques tests, mais on n'a pas eu le temps d'en faire des masses. On a testé Google Page Insights et gémétrics. J'ai vu que, du coup, pour HTTP2, par logique, effectivement, on déconseille l'amnification et la concatenation. Ma question du gros, est-ce que Google va continuer à être content, du coup, avec ce Page Insights ? Alors, la minification, non, ça, c'est... Ouais, la concatenation, par contre. La concatenation, par contre, oui. Alors, je pense que, étant donné que Google est derrière le projet et le soutient, c'est activement, enfin, et à l'origine du truc, je pense que, si c'est pas déjà le cas, ils vont très rapidement changer les règles au niveau de la concatenation. Je pense que ça, c'est pas trop un souci. Ok, d'accord, super. Merci. Bonjour. Je voulais juste savoir si le fait de passer en SSL, ça va l'influencer sur les bénéfices en termes de performance, puisque le SSL, en général, est moins performant que l'accès direct. Ouais. Alors, il y a un impact, évidemment, qui existe. Cependant, il est très réduit quand on est en HDP2 parce qu'il n'y a qu'une seule connexion de TCP, donc il n'y a qu'une... On fait la négociation SSL qu'une seule fois. Donc, c'est un impact qui est réduit par rapport, très clairement, par rapport aux gains que ça apporte derrière. C'est pas... Donc, oui, c'est quand même mieux, même si ça implique de façon SSL de façon HDP2. Petite question de novice. Du coup, si on veut passer en HDP2, les actions réelles, c'est des actions à minus 6 sur le serveur, concernant WordPress, c'est ce qu'il y a des... des choses à mettre en place pour changer les haideurs, voilà, qu'elle est la... la démarche de mise en pratique. OK. Justement, l'idée, c'était de montrer qu'il n'y avait rien à faire globalement, enfin, à part passer en SSL et puis arrêter les optimes pour... d'un point de vue developer WordPress. D'un point de vue fissaline, il y a pas mal de table, oui. Ouais, après, ça dépend du niveau de... de compatibilité qu'on veut. Nginx, aujourd'hui, est compatible, mais il va pas supporter le serveur push. Et on ne le voit pas encore sur les prévisions, là, courme et interme. Ils en parlent pas beaucoup. Donc, du coup, après, il faut aller s'amuser avec des choses un petit peu plus exotiques si on veut vraiment profiter à fond du... du protocole. D'accord. Et selon toi, du coup, combien de temps on sera dans une norme relativement stable qu'on pourra implémenter et je dirais même qu'ils deviennent l'implémentation par défaut ? Alors, c'est... c'est compliqué à... Non, je sais pas, mais en tout cas, ce qui est sûr, c'est qu'aujourd'hui, enfin, il y a pas mal de monde qui commencent à le faire, bien. Donc, c'est... c'est stable. C'est pas un problème de stabilité. Aujourd'hui, c'est plus un problème de legacy qui fait que, bah, c'est compliqué de... de passer, de se mettre à jour, de tout changer pour être compatible. Parce que voilà, les choses changent plus lentement que la vitesse de développement des protocoles, etc. Donc, forcément. Mais donc, non, si on en fait l'effort, aujourd'hui, on peut le faire. Donc, ça, c'est la première réponse. Après, combien de temps ça va mettre pour les hébergeurs ? Je pense que très sincèrement, à partir du moment où il va y avoir les premiers gros hébergeurs qui vont s'y mettre, il y a une telle compétitivité dans l'espace que ça va aller très, très vite, quoi. En fait, on vient de penser à une chose dans WordPress. C'est que ça, c'est valable pour un site qu'on crée, pour un site qu'on migre sous HTTPS. Faut penser à réécrire toutes les URL, faire l'ingression d'URL, etc. Et l'activer dans un config. C'est pas une chose négligeable. On peut perdre son référencement assez facilement si on fait pas attention à ça. Ouais, absolument. Je préfère le préciser. Non, non, mais je l'ai oublié, en fait. Absolument. Non, je ne suis pas rentré en détail de comment on passe son SSL, c'est bien votre main slide, on passe en SSL. C'est vrai que derrière, ça implique pas mal d'autres choses. Merci. Si on a un navigateur, je dirais qu'il supporte HTTPS 1, un problème, bien évidemment, et HTTPS 2, un serveur qui supporte les deux aussi, comment le navigateur dans le protocole va savoir que le serveur supporte ou ne supporte pas. C'est-à-dire comment on va basculer ou on ne va pas basculer. C'est indiqué dans les requêtes, dans les réponses, dans les réponses envoyées par le serveur, il va indiquer qui supporte. D'accord, donc un navigateur qui supporterait pas le HTTPS 2, comment il va gérer une réponse HTTPS 2. C'est-à-dire comment on passe dans un monde actuel où il y a peu de HTTPS 2, à un monde futur où chacun sera quoi faire avec qui. C'est ce que je disais, la rétro-compatibilité sur le détail technique de comment le navigateur fait ça dans le détail. Merci pour la conférence. Est-ce qu'en cas d'une mauvaise bande passante, est-ce qu'il y a un système de callback ? C'est-à-dire ? C'est-à-dire en fait si j'ai par exemple un site d'Eberge en Afrique par exemple ou bien dessiné pour une clientèle non africaine, est-ce que je peux faire des... l'Eberge sur deux protocoles HTTPS, et puis HTTPS 2 ? Oui non mais c'est ça, c'est-à-dire que si en fait il n'y a pas besoin de l'Eberge deux fois, c'est juste que si le navigateur derrière n'est pas compatible, il va fonctionner en mode HTTPS 1. Merci, merci Laurent, on peut leur applaudir.