Je suis tout à fait d’accord. Mon résultat de recherche rapide n’était pas le point central et n’a certainement pas été présenté comme un test d’autorité quelconque ; et lorsque je l’ai publié, je n’ai pas fait de telles affirmations non plus. Je posais simplement une question basée sur mes résultats de recherche. J’aurais dû me déconnecter avant de faire la recherche, car lorsque je me déconnecte, j’obtiens les mêmes résultats « manquants », LOL.
Le seul « point technique tangible » que j’ai réellement avancé est que Google a publiquement déclaré qu’il utiliserait le LCP (et d’autres indicateurs Web) à partir de mai 2021.
J’ai également soulevé un argument commercial : Google ne peut pas faire de déclarations de ce type et tromper les gens. Ce serait une énorme erreur pour une grande entreprise cotée en bourse. Mon hypothèse est qu’ils ne commettent pas une telle erreur, et lorsque Google déclare qu’il n’utilise pas encore le LCP comme signal, je n’ai aucune raison de ne pas les croire.
Si les contributeurs bien intentionnés qui soutiennent que le LCP affecte le référencement et qui affirment être sûrs de « leurs conclusions », tout en prônant des changements structurels dans le code de Discourse en raison de ces « conclusions », avaient accès au code pour examen, en open source, afin que chacun puisse l’examiner, leurs « preuves », après un examen par les pairs, pourraient être convaincantes.
Il ne s’agit en rien d’une attaque personnelle ou d’une hostilité ; en fait, nous n’avons vu que quelques graphiques et aucun code, alors que Google a publiquement déclaré qu’il n’utilisait pas encore le LCP comme signal de référencement pour le moment.
Dans un souci d’« équité technique », nous n’avons en réalité vu aucune « preuve » que Google utilise actuellement le LCP comme signal. Ce n’est qu’une hypothèse et il n’y a aucun code à examiner pour étayer cette affirmation par un examen par les pairs.
Tout le monde ici aimerait savoir quelles modifications sont nécessaires pour optimiser le référencement et augmenter les revenus. Cependant, nous avons besoin de faits tangibles, de code à examiner, pour être convaincus que Google utilise réellement le LCP comme signal.
Google affirme qu’il n’utilise pas actuellement le LCP comme signal et commencera à l’utiliser comme signal de référencement en mai 2021. Jusqu’à présent, nous n’avons vu aucune raison de douter de ce que Google a déclaré publiquement ; et nous n’avons vu aucune « preuve solide et examinée par les pairs » allant à l’encontre de cela.
Alors, pour tous ceux qui se sont plaints de mai 2020, ce n’était rien comparé à ce qui pourrait arriver en mai 2021 ? Je veux dire, vous dites aussi que les communautés Discourse pourraient subir un coup dur en termes de résultats de recherche l’année prochaine (nous verrons déjà ce qui se passe).
Oui, je suis tout à fait d’accord avec vous et avec tous ceux qui sont ici préoccupés par le LCP et l’impact que les Core Web Vitals de Google vont avoir.
De plus, je félicite vivement tous ceux qui s’activent pour trouver des réponses et des solutions face à ce problème imminent.
Concernant le crash SEO de mai 2020, cela nous est également arrivé sur des serveurs LAMP ; ce n’est donc absolument pas un problème inhérent à Discourse en soi, et nous ne connaissons toujours pas les étapes exactes pour résoudre ce problème de mai 2020, car si nous savions quoi corriger avec un haut degré de certitude, nous pourrions tous « corriger » et « ajuster ».
Au fil des ans, nous avons tous observé des résultats très étranges de la part de l’IA de Google, notamment sur la façon dont elle classe le contenu et modifie les résultats des SERP.
Mon point précédent était qu’il me semblait peu étayé de lire dans ce sujet des appels à l’équipe Meta de Discourse pour qu’elle procède à des changements structurels majeurs dans tout son écosystème, basés sur des hypothèses et des suppositions plutôt que sur des faits concrets issus d’un examen du code.
Cela dit, le LCP va devenir très important, et ce, en un clin d’œil.
C’est ainsi que fonctionne Discourse depuis toujours
La nouveauté, c’est que le LCP est capturé depuis les téléphones Android des utilisateurs. Android est la plateforme la plus lente sur laquelle nous tournons, et cela nous affecte de manière disproportionnée.
Ce que @sam a suggéré consistait également à servir cette vue à certains utilisateurs anonymes via un plugin, mais ce n’est pas quelque chose que nous ferons prochainement.
D’accord. Je manque de connaissances sur son fonctionnement exact (mais il semble qu’il y ait encore du chargement initial à optimiser, et cela pourrait être plus rapide. D’où tout ce sujet). Cette discussion a déjà eu lieu en quelque sorte le 14 octobre, ci-dessus. Jeff lui-même a en fait soulevé l’idée :
Pourquoi ne pas prendre le contenu et créer un site statique totalement pré-généré. Quelque chose aussi rapide que possible. Et soumettre cela aux moteurs de recherche au lieu du forum réel ? L’idée serait que le contenu est le plus important ici, pas l’expérience. Et se concentrer sur la rapidité de la livraison, car c’est ce qui semble important pour les moteurs de recherche.
Le défilement infini n’a pas été blâmé récemment, mais vous créeriez des pages statiques pré-générées sans défilement infini. Et vous le concevriez comme une voiture de rallye : Chaque gramme de poids qui n’est pas strictement nécessaire, vous vous en débarrassez. Pas de menu hamburger, pas de logo, pas d’avatar pour les auteurs. Vous vous concentrez uniquement sur le contenu et la vitesse.
Ce serait comme un bon restaurant (= le forum Discourse), où vous installez un drive avec des commandes à emporter. La même excellente nourriture (= le contenu) mais sans aucune de l’expérience. Vous commandez à un haut-parleur en arrivant (= votre recherche sur le moteur de recherche) et vous obtenez votre nourriture préemballée jetée par votre fenêtre. Toute l’idée est que c’est ce qui est demandé, et seule la nourriture (= contenu) et la rapidité de la livraison comptent. Si les gens aiment la nourriture, peut-être qu’ils reviendront pour profiter de toute l’expérience à l’intérieur.
Après, c’est à chaque propriétaire (= administrateur) de faire un choix : pensez-vous qu’un drive est mauvais pour votre marque et que vous refusez de le faire, ou suivez-vous cette voie pour attirer plus de gens, sachant que beaucoup ne viendront peut-être jamais manger à l’intérieur (beaucoup ne le font déjà pas, mais cela pourrait empirer. Et peut-être que votre restaurant semblera beaucoup moins agréable présenté de cette façon). Mais peut-être que ce site web célèbre qui recommande des restaurants vous enverra plus de monde (il reste à voir si c’est efficace).
Ce qui serait nécessaire, c’est un plugin ou module pour générer ces pages statiques au fur et à mesure que le contenu est ajouté au forum (je suppose que cela ne devrait pas être trop compliqué). Vous ajouteriez simplement un lien ici et là vers votre forum réel (configuré sur “ne pas crawler” pour les moteurs de recherche). Il appartiendrait à chaque administrateur d’utiliser cette solution ou non.
Si ce qui a été dit ci-dessus est correct dans le principe, et que ce problème pourrait empirer à l’avenir, cela me semble être une solution acceptable. Ou peut-être que je n’ai pas bien compris. (Note: tout cela serait EN LECTURE SEULE, bien sûr)
Nous servons déjà du HTML brut sans JavaScript aux robots d’indexation
Comme je l’ai dit plus haut, le problème est que le nouveau score LCP est capturé depuis les navigateurs des utilisateurs, et non depuis les robots d’indexation.
D’accord, mais ce que je ne parviens pas à comprendre, c’est que personne ne s’en sort mieux dans ce cas, n’est-ce pas ? Pourquoi cela aurait-il un impact sur les résultats de recherche ? Si les sites Discourse se comportent aussi bien que les autres (« aussi bien » ou « aussi mal » ;)). Les autres sites sont-ils également ouverts sur Android, non ?
Android est plus lent que la moyenne en matière de performances monocœur, ce qui affecte les applications monopages lourdes comme Discourse. Nous abordons ce sujet en détail dans L’état de JavaScript sur Android en 2015 est… médiocre
L’iPhone le plus performant est 10 fois plus rapide que le dernier Pixel lors du rendu de Discourse. Google ne prend pas en compte les rendus iPhone dans le LCP, car cela est simplement impossible, puisqu’il n’existe pas de véritable Chrome sur iOS.
Il pourrait donc y avoir effectivement un avantage dans ce domaine à générer un site de « petites pages » à soumettre aux moteurs de recherche. Est-ce que cela en vaudrait la peine ? (peut-être pas). Ou les administrateurs doivent-ils offrir de nouveaux téléphones haut de gamme à leurs utilisateurs ? C’est le but de toutes ces publicités affirmant que vous avez gagné le dernier iPhone ?
En parcourant rapidement cette page Overview of CrUX | Chrome UX Report | Chrome for Developers, il semble que Google obtienne les informations en espionnant les utilisateurs (avec leur autorisation). Vous devriez donc convaincre beaucoup d’entre eux d’utiliser votre Discourse bon marché
Il semble que vous confondiez Ember et Ember CLI. Ember est le framework que nous utilisons déjà (et que nous utilisons depuis plus de 8 ans). Ember CLI est l’ensemble d’outils en ligne de commande vers lequel nous migrons, plutôt que d’utiliser le pipeline d’actifs de Rails. Je le mentionne car certaines de vos affirmations (les versions antérieures à la 3 nécessitent une réécriture) ne seraient pas vraies pour Ember CLI, mais pourraient l’être pour Ember.
Encore une fois, Ember CLI ne gère pas le rendu. C’est Ember qui le fait, et il a parfois des problèmes de performance. Notez que cela n’est pas spécifique à Ember : tous les frameworks actuels ont des pièges de performance dont il faut être conscient. Après des années de travail avec Ember, nous avons identifié deux chemins critiques (la page d’accueil et la vue des sujets) qui nécessitaient de meilleures performances, et nous avons opté pour une approche basée sur un DOM virtuel.
Nous ne serons peut-être pas toujours obligés de le faire, selon la façon dont Glimmer/Ember Octane évoluera, mais le code est désormais très stable et fonctionne rapidement, même sur les anciens appareils mobiles.
Ember Octane a été introduit dans la version 3.15, et deux versions LTS ont été publiées depuis (3.16 et 3.21). Nous allons passer à cette version, mais par étapes. Heureusement, l’équipe d’Ember vous permet de choisir (même fichier par fichier !) le format que vous souhaitez utiliser.
Cela étant dit, il y a beaucoup de choses à critiquer concernant Ember. À l’époque où les performances étaient un problème plus important pour Discourse, plusieurs versions promises nous ont finalement nui plutôt que de nous aider. Ce fut difficile. Nous avons dû garder un œil très attentif dessus pendant longtemps pour répondre à nos besoins.
Aujourd’hui, il a également une fraction de la popularité de frameworks plus récents comme React. Cependant, React n’existait pas il y a 8 ans ! Nos seuls choix étaient Angular, Ember et Knockout. Si vous pensez que la mise à niveau d’Ember est difficile, vous devriez voir ce qu’Angular a traversé entre les versions 1 et 2 (sans parler de leurs détours avec Dart !).
La mise à niveau d’Ember au fil des ans a été un gros travail, mais au moins c’est une option ! Aucun des autres frameworks n’offrait une telle voie de mise à niveau.
En ce qui concerne la réécriture en Vue/Next/React, je pense que les gens sous-estiment gravement la quantité de code que nous avons et qui fonctionne très bien. Ce serait un travail inimaginable.
Je suis en train d’y réfléchir @justin et @awesomerobot, mais je voulais que Robin donne son avis sur les spécificités d’Ember CLI en premier.
À la base, il y a un peu ce paradoxe du « Que se passe-t-il lorsqu’une force irrésistible rencontre un objet immuable ? » : nous sommes très intentionnellement une application JavaScript (ou une SPA), ce qui implique des compromis que nous avons décidés en 2012/2013 en nous basant sur notre meilleure estimation de l’avenir en 2022/2023. Bien que je sois évidemment partial, je dirais que notre prédiction selon laquelle « eh bien, les performances des navigateurs sur les appareils mobiles seront indiscernables de celles des navigateurs de bureau » était tout à fait exacte.
Bon, même au-delà de nos attentes, car la plupart des téléphones Apple récents sont plus rapides que les ordinateurs portables et les ordinateurs de bureau. Ça, je ne m’y attendais pas du tout !
Bien que nous continuions à améliorer ce que nous pouvons en termes de vitesse de chargement initial — et de vitesse en général — je pense que notre bilan dans ce domaine est louable. D’une part, nous avons obtenu une telle publicité en 2015 que Google a internement apporté plusieurs améliorations à V8, Chrome et Android pour remédier aux faibles performances des SoC Qualcomm mesurées en JavaScript.
Notre talon d’Achille a été .. Qualcomm. Malheureusement, Qualcomm n’a pas très bien performé sur le plan des performances à ce jour, car le dispositif Android « le mieux » performant n’atteint que le niveau approximatif d’un iPhone 7. Il faut beaucoup de temps pour que les anciens appareils Android disparaissent du marché, mais les 855 et 865 étaient tous deux de bons performeurs, environ au niveau d’un iPhone 7 :
Je dois faire défiler plus bas pour atteindre un appareil Apple aussi lent que l’appareil Android le plus rapide, mais si je le fais, le correspondant le plus proche est l’iPhone X / iPhone 8 avec environ 910 points dans Geekbench. Malheureusement, le 865, pour des raisons que je ne comprends pas entièrement, sous-performe un peu côté web, nous sommes donc toujours au niveau des performances de l’iPhone 7 dans Speedometer :
J’aimerais vraiment que nous vivions dans un monde où il existerait des appareils Android équipés de divers SoC provenant de différentes entreprises qui rivaliseraient pour construire les SoC les plus rapides et les plus puissants.. En revanche, les performances de l’iPhone 7 sont solides pour Discourse et je suis heureux que finalement tous les appareils Android, même les anciens, seront « au moins aussi rapides qu’un iPhone 7 ». Je croise aussi les doigts pour le prochain Snapdragon 875 ; il devrait y avoir plus de détails à ce sujet dans les mois à venir.
Selon les résultats de Geekbench 5, nous pouvons voir que le Xiaomi Mi 11 est alimenté par le Snapdragon 875 en 5 nm (comme l’a laissé entendre nul autre que l’exécutif de Xiaomi, Lu Weibing). Le futur Xiaomi Mi 11 a réussi à obtenir 1 102 points dans le test monocœur et 4 113 points dans le test multicœur.
Si c’est vrai, cela le placerait au niveau de l’A12, et j’espère que cela se traduira également côté web !
Quoi qu’il en soit, il y a ici une décision architecturale fondamentale chez Discourse : être une application JavaScript… et nous sommes pleinement engagés dans cette voie pour le futur prévisible.
Pour ceux qui surveillent vos statistiques, voici une autre date à noter. Il sera intéressant de voir ce qui se passera dans les semaines à venir en relation avec la dernière mise à jour de base de Google, décembre 2020.
On ne peut pas oublier les Macs récents équipés de puces Apple Silicon !
Par curiosité, d’où venait cette publicité ?
La puce A10 tient encore à un fil.
Par précaution, je baisse mes attentes. Apple a toujours été en avance.
Cela dit, les smartphones Android tentent encore de rattraper leur retard. C’est tout simplement ridicule. Apple dispose déjà de la puce A14 et travaille probablement déjà sur la puce A15 pour l’année prochaine.
Merci de l’avoir partagé. Voici quelques éléments pertinents de cette discussion à extraire de l’article :
Que faire si vous êtes touché. Google a déjà donné des conseils sur les points à envisager si vous êtes négativement affecté par une mise à jour de l’algorithme principal. Il n’existe pas d’actions spécifiques à entreprendre pour récupérer, et en réalité, un impact négatif sur le classement peut ne pas indiquer qu’il y a un problème avec vos pages. Cependant, Google a proposé une liste de questions à se poser si votre site est touché par une mise à jour de l’algorithme principal. Google a également indiqué que vous pourriez observer une légère récupération entre deux mises à jour de l’algorithme principal, mais le changement le plus significatif que vous constateriez surviendrait après une autre mise à jour de l’algorithme principal.
À mon avis, lorsqu’on parle de référencement naturel (SEO), c’est-à-dire de l’optimisation des résultats des moteurs de recherche par rapport à d’autres sites, parler du matériel des utilisateurs est largement hors de propos.
Pourquoi ?
C’est en fait assez simple.
Prenons le cas d’une personne et de ses résultats de recherche sur son appareil mobile.
Quelle que soit la vitesse de son appareil ou le type de puce utilisée, les performances seront similaires sur tous les sites web, car l’expérience utilisateur finale (les performances) d’un seul appareil utilisateur sur le réseau sera, pour la plupart, identique sur tous les sites web de performances comparables. Les sites plus rapides seront plus rapides et les sites plus lents seront plus lents, indépendamment de la puce ou d’autres caractéristiques de l’appareil de l’utilisateur final. Une marée montante soulève tous les bateaux, et une marée descendante les fait tous couler. En SEO, les appareils des utilisateurs finaux constituent du « bruit » par rapport au signal de référencement, comparé à l’application serveur, qui est ce qui est optimisé dans le « SEO ».
Ainsi, même si un téléphone mobile est le plus rapide de tout l’univers, tous les sites web seront rapides (ou lents) en fonction de la vitesse du réseau et de la conception du site. L’objectif du SEO est d’optimiser l’application web et sa diffusion, et non les appareils des utilisateurs finaux. Si une application web fonctionne « de manière incroyable » sur une puce donnée, tous les autres sites web de conception similaire fonctionneront de la même manière. Le focus du SEO n’est pas l’appareil de l’utilisateur final ; il s’agit de l’optimisation de l’application web, du contenu, du temps de chargement basé sur le serveur, et non de l’appareil client. Les appareils clients visitent, en théorie, tous les sites web, et tout cela constitue du « bruit » dans le rapport signal/bruit du SEO.
Du point de vue du référencement d’un site web, votre optimisation pour les moteurs de recherche basée sur l’expérience utilisateur sera la même sur tout le réseau pour tous les utilisateurs appartenant à une même classe (caractéristiques de performance) d’appareils mobiles. La seule chose qui donnera un avantage SEO à un site web par rapport à un autre est la performance du site web (et de son réseau), et non celle des appareils des utilisateurs finaux.
Pourquoi ?
Parce que les appareils des utilisateurs finaux fonctionneront de la même manière sur tous les sites web, de manière générale. Si le mobile de l’utilisateur est lent en raison de la mémoire ou de la puce, il sera lent dans tout le cyberunivers des sites web. Autrement dit, la discussion sur l’impact des appareils des utilisateurs finaux sur le SEO est vaine. L’optimisation pour les moteurs de recherche est une opération côté serveur, et non côté client.
Ce qui compte, c’est le contenu, la présentation et les performances, ainsi que la manière dont l’IA de Google évalue ces facteurs dans tout le cyberunivers. Par exemple, si tout le monde dans le monde entier passait à des téléphones mobiles dotés d’ordinateurs quantiques, le SEO resterait le même, car tous les utilisateurs finaux auraient les mêmes « courbes de performance des appareils ». L’optimisation se fait au niveau du fournisseur (le site web). De même, si tout le cyberunivers se dégradait vers des téléphones mobiles avec des puces lentes, les classements des moteurs de recherche resteraient largement les mêmes, car l’optimisation nécessaire se fait au niveau des serveurs qui diffusent le contenu web.
Bien sûr, Discourse, en tant qu’application monopage (SPA) pilotée par JavaScript, fonctionnera mieux après le chargement si les mobiles sont plus rapides. Il en va de même pour tous les autres sites web ! En général, ce sont les performances du réseau ainsi que celles du serveur qui comptent, et non l’appareil de l’utilisateur final en ce qui concerne le SEO. Ce n’est pas mon opinion, c’est un fait scientifique et technique. Mon opinion ou mon attachement émotionnel à JavaScript ou à EmberJS ne change pas le fonctionnement du SEO. Ce qui fonctionne pour le SEO, c’est le contenu et les performances de l’application web.
Pour conclure, Google utilise une IA avancée, principalement des réseaux de neurones artificiels, pour déterminer comment il classe et indexe le contenu web. L’optimisation pour les moteurs de recherche repose sur la manière dont l’IA de Google classe le site, les performances du site et son « attrait pour l’IA de Google ». Le fait que nous aimions JavaScript, Ruby ou Python, ou que nous admirions l’élégance et les mécanismes de toute application web que nous fournissons aux utilisateurs finaux, n’a pas d’importance, sauf si notre passion pour notre application séduit l’IA de Google et si nous créons un contenu unique, bien présenté à l’IA de Google, et tel que l’IA de Google perçoit les performances, et non telle que nous les percevons nous-mêmes.
Nous ne classons pas nos propres sites web. C’est l’IA de Google qui effectue le classement.
Comme Google l’a déclaré publiquement :
« Une façon de comprendre le fonctionnement d’une mise à jour principale est d’imaginer que vous avez établi une liste des 100 meilleurs films de 2015. Quelques années plus tard, en 2019, vous actualisez cette liste. Elle va naturellement changer. De nouveaux et merveilleux films, qui n’existaient pas auparavant, deviendront des candidats à l’inclusion. Vous pourriez également réévaluer certains films et réaliser qu’ils méritaient une place plus élevée sur la liste qu’auparavant. La liste changera, et les films précédemment classés plus haut qui descendent ne sont pas mauvais. Il existe simplement des films plus méritants qui les devancent », a écrit Google.
La société a proposé la liste de questions suivante à prendre en compte lors de l’évaluation de votre contenu :
Le contenu fournit-il des informations originales, des reportages, des recherches ou des analyses ?
Le contenu fournit-il une description substantielle, complète ou exhaustive du sujet ?
Le contenu fournit-il une analyse approfondie ou des informations intéressantes qui vont au-delà de l’évidence ?
Si le contenu s’appuie sur d’autres sources, évite-t-il de simplement copier ou réécrire ces sources et fournit-il plutôt une valeur ajoutée substantielle et de l’originalité ?
Le titre de l’article et/ou le titre de la page fournissent-ils un résumé descriptif et utile du contenu ?
Le titre de l’article et/ou le titre de la page évitent-ils d’être exagérés ou choquants ?
Est-ce le genre de page que vous voudriez enregistrer en favoris, partager avec un ami ou recommander ?
Vous attendriez-vous à voir ce contenu dans un magazine imprimé, une encyclopédie ou un livre, ou qu’il y soit référencé ?
C’est cela le SEO, et l’activité principale de Google consiste à créer des algorithmes permettant aux machines de noter et de classer les sites web.
Cela est incompatible avec les faits : nous savons que Google collecte des temps de chargement réels des pages sur les appareils Android et les utilise pour le classement des pages.
Oui, mais tous les appareils Android (du même type) affichent globalement les mêmes performances pour tous les sites web (du même type). Autrement dit, si vous optimisez un site web basé sur JavaScript utilisant webpacker et bundler, vous êtes en concurrence, du point de vue du référencement, avec tous les autres sites qui sont des SPA JavaScript utilisant webpacker et bundler, etc.
Je n’ai pas dit que Google ne collecte pas ces informations. J’essaie d’expliquer que se concentrer sur l’appareil client ne résoudra pas le problème de performance du référencement des SPA. Une « marée montante fait flotter tous les bateaux » : un processeur plus rapide qui traite bien le JavaScript compressé (rapide, optimisé, etc.) affichera de bonnes performances sur tous les sites web similaires.
Autrement dit, le référencement se situe du côté du serveur (comme je l’ai expliqué en détail ci-dessus), et non du côté du client.
Ceci est d’ailleurs bien documenté.
Peu importe :). Je préfère ne pas débattre de ce sujet ici sur meta. Merci.
Google a été très clair sur les signaux de référencement qu’ils considèrent comme importants, maintenant et jusqu’en 2021. Ils redessineront constamment leur IA en fonction des événements et des situations dans le cyberespace.
D’un point de vue SEO, vous êtes en effet en concurrence avec des sites techniquement similaires.
Mais d’un point de vue commercial, vous êtes en concurrence avec d’autres sites de votre marché, indépendamment de leur technologie. Cela pourrait amener certaines personnes à envisager de passer à une technologie perçue comme « meilleure » d’un point de vue SEO. Et c’est la situation dans laquelle se trouvent certaines personnes.
Je veux dire, vous dites aussi que les communautés Discourse pourraient subir un coup dur en termes de résultats de recherche l’année prochaine (nous verrons déjà ce qui se passe).
Ça, je ne m’y attendais pas du tout !
En revanche, les performances de l’iPhone 7 sont solides pour Discourse et je suis heureux que finalement tous les appareils Android, même les anciens, seront « au moins aussi rapides qu’un iPhone 7 ». Je croise aussi les doigts pour le prochain Snapdragon 875 ; il devrait y avoir plus de détails à ce sujet dans les mois à venir. 
