Comment Weglot permet de traduire instantanément et sans friction +100K sites web dans le monde

0:07 On va arrêter en fait, parce que déjà là, c'est bon. Qui a été ému, touché? Ça, on aime bien. Cœur, cœur, on adore. On va continuer en fait, parce que vous savez que le talent du Tech.Rocks Summit, c'est évidemment d'enchaîner les talks inspirants, inspirants d'un point de vue tech pour vous, pour que vous puissiez piocher des choses pour votre quotidien, pour votre propre profession, mais aussi ouvrir un peu les chakras sur d'autres types de résilience, pour qu'on reparte chargé. Parce qu'on n'est pas que des machines. Nous sommes aussi des humains. Et justement, on va en accueillir deux, des humains. Alors, il va falloir vous préparer. Vous savez qu'il y a un truc que j'aime beaucoup au théâtre, c'est... Alors, je ne sais pas si vous l'avez remarqué ce matin, pour ceux qui étaient là dès l'introduction, c'est les vaudevilles. On rentre, on sort, on claque les portes, tout ça, machin. C'est assez drôle. Si elle, mon mari, oups, mon amant, voilà. On n'arrête pas, d'ailleurs, c'est ce qui se joue en ce moment au Théâtre de Paris.

1:11 Alors là, c'est pareil, on va vivre une scène qui est digne d'un des meilleurs vaudevilles technologiques. Non, je n'ai pas peur des mots, ça va être un des meilleurs vaudevilles technologiques. Il n'y a pas de porte qui claque, ni de valet caché sous les lits, mais des sites web traduits plus vite qu'un amant ne file par la fenêtre. Sur les planches. Deux protagonistes, Clément Schoehn, qui est directeur commercial chez Cloudflare, qui est le chef d'orchestre d'un réseau serverless si rapide qu'on jugerait qu'il a même des patins aux pieds. Et Nicolas Dechevigné, qui est Head of Engineering chez Weglot, virtuose de la traduction instantanée, capable de faire passer... Un site du français au japonais avant même que vous ayez dit« quiproquo». Donc ensemble, ils vont nous révéler comment Weglot fait parler plus de 100 000 sites web dans toutes les langues, sans friction ni stress, mais grâce à Cloudflare. Acte 1, scène 3, Clément Schoehn et Nicolas Dechevigné. Messieurs, vous avez 25 minutes.

2:17 La scène du Théâtre de Paris est à vous. Super, merci. Bonjour à tous. Alors moi, c'est Clément. Je suis chez Cloudflare depuis un peu plus de 4 ans et demi maintenant. Et j'accompagne nos clients, certains d'entre vous étant dans la salle, sur des sujets de performance, de cybersécurité, de connectivité et de développement. Et quand on nous a demandé de venir présenter un sujet aujourd'hui au Tech.Rocks Summit, on s'est dit que ce serait peut-être intéressant de vous faire témoigner un client avec un retour d'expérience concret sur la manière dont il utilise Cloudflare. Et je suis ravi aujourd'hui, ce matin, d'avoir à mes côtés Nicolas de chez Weglot. Salut Nicolas. Salut Clément. Du coup, le sujet d'aujourd'hui, c'est comment traduire instantanément et sans friction plus de 100 000 sites web à travers le monde. C'est le pari qui a été relevé par Weglot. Et avant de rentrer dans le vif du sujet, je voulais vous faire une petite présentation rapide de Cloudflare.

3:22 Je pense que certains, beaucoup d'entre vous, nous connaissent peut-être déjà, mais pas forcément sur l'ensemble des services qu'on est capable de proposer. Donc Cloudflare, initialement, ça a été créé il y a un peu plus de 15 ans maintenant pour protéger les sites web. qui fonctionne, pour protéger les sites web des attaques, notamment des attaques DDoS. Une attaque DDoS, c'est des attaques qui sont volumétriques, qui sont distribuées. Et la meilleure manière de protéger des sites de ce type d'attaque, c'est de construire également un réseau qui est lui aussi capable d'absorber énormément de trafic, notamment en étant distribué. Avec des points de présence à travers le monde qui sont capables de supporter l'ensemble de nos services. Donc à l'époque, uniquement de la protection anti-dédos. Et puis au fur et à mesure qu'on a commencé à essaimer des points de présence dans toutes les villes, les principales villes du monde, on s'est dit qu'on pouvait utiliser ce réseau pour faire davantage de choses.

4:27 Vous nous connaissez peut-être sur la brique CDN, sur la brique DNS également. Ce réseau nous permet aussi d'utiliser les connexions qu'on a à travers ces points de présence à travers le monde dans l'autre sens pour fournir des services de Zero Trust. Et une fois qu'on s'est dit qu'on était à proximité de là où nos services sont consommés, on s'est dit, tiens, pourquoi est-ce qu'on ne pourrait pas proposer aux développeurs de créer des applications et d'héberger, entre guillemets, leurs services, en tout cas de faire tourner leurs services au plus... près de là où ils sont consommés. Et c'est ça, toute la notion du edge, qui va être intéressante dans le témoignage de Weglot et qui leur permet d'être ultra efficace, ultra rapide et ultra résiliente, puisque c'est le sujet d'aujourd'hui et de cette session Tech.Rocks. Voilà pour moi. Du coup, je passe la main à Nicolas pour nous présenter Weglot. Merci Clément. Oui, c'est ça. Alors Weglot, nous traduisons des sites Internet.

5:29 On essaye de le faire le plus simplement, le plus rapidement possible. Le but, c'est vraiment d'être compatible avec tous les sites Internet. En fait, on est parti du constat où être une dépendance, être compatible avec un langage informatique, c'était beaucoup trop compliqué à maintenir. Ça s'adressait un peu trop aux développeurs. Nous, on voulait quelque chose de simple à mettre en place, avec même un moyen de prévisualiser son site Internet tout de suite traduit pour pouvoir ce que ça pouvait donner. Et donc, pour ça, en fait, ce qu'on a fait, c'est qu'on est parti du HTML. Tous les sites, au final, ne sont pas faits en HTML, mais le navigateur ne comprend que le HTML. Et donc, tous les sites, au final, sont faits avec du HTML, et le texte se trouve dans le HTML. Donc, nous, on a fait quelque chose de compatible avec du HTML. En étant compatible avec le HTML, on est compatible avec tous les sites. Donc on peut traduire toutes les technologies des sites e-commerce.

6:30 des sites corporate, des landing pages. Je sais qu'on traduit le site de ShipUp qui sont présents ici. Même des applications protégées, des SaaS. Le but, ça va être d'améliorer la compréhension du site en le traduisant, pour ceux qui ont besoin de l'avoir dans leur langue, et surtout d'améliorer le référencement, d'augmenter des ventes, surtout dans le cas d'un site e-commerce. Être compatible avec le HTML, on l'a fait avec plusieurs moyens, on propose plusieurs possibilités de nous intégrer. En gros, concrètement, l'une des possibilités, ça va être de demander à notre utilisateur de rajouter une ligne de HTML, ça va être un script. C'est vraiment une balise script, on rajoute une lib, enfin un module JavaScript pour être plus précis. Et ce module, il va s'exécuter pendant le chargement de la page, et puis en fait, il va aller récupérer les textes, il va aller les envoyer à une API qu'on a développée en interne, une API de traduction, on envoie des textes et

7:35 on récupère les traductions, on va changer les textes par les traductions, et donc en fait, ça va se passer côté client. Et on a développé une autre solution qui se base côté serveur, où là on va se placer en tant que proxy, donc là on ne va pas aller demander à notre utilisateur d'ajouter une ligne de HTML, on va simplement lui demander de changer les DNS de son site vers nos serveurs. Et à partir de là, on a la main. sur ce qu'on peut renvoyer. On se place en tant que proxy et on a la capacité de modifier tout le contenu du site. C'est comme ça qu'on traduit tout votre site avec le nombre de langues que vous voulez, absolument toutes les pages, alors que vous avez juste changé les DNS de votre site. Vraiment, ça ne demande aucune connaissance technique, mis à part changer des DNS, mais on peut vous accompagner pour ça. Et donc, on va s'attarder aujourd'hui sur cette deuxième solution, la solution par proxy. Et c'est dans ce cadre-là que nous utilisons Cloudflare.

8:36 Super. Alors du coup, juste peut-être avant de rentrer dans le vif du sujet de l'utilisation de Cloudflare, j'imagine que quand on a la responsabilité d'un SaaS qui est capable de traduire instantanément des centaines de milliers de sites en plusieurs dizaines de langues, on fait face à certains enjeux. Est-ce que tu peux nous en partager quelques-uns? Oui, évidemment. Si on s'attarde vraiment sur le sujet du proxy, où on prend la main sur le domaine, il y a les sujets de sécurité. Il va falloir délivrer le certificat SSL. Il y a des sujets de performance, parce qu'évidemment, il ne faut pas qu'on ralentisse le site d'origine. Des sujets de scalabilité, il faut qu'on soit capable d'absorber toutes les requêtes du site en question. Parce que toutes les requêtes vont passer par... nos serveurs, en l'occurrence, ce sont les leurs qu'on utilise. Et puis après, une capacité à pouvoir intégrer la logique qu'on a envie de mettre en place,

9:47 être en capacité de traduire finement chaque site internet, donc avec une logique codée en JavaScript qu'on peut mettre en place grâce à vos workers. Super. Du coup, qu'est-ce qui a mené ces enjeux vers Cloudflare initialement ? Est-ce qu'il y avait certaines fonctionnalités que vous ne trouviez peut-être pas ailleurs ou qui ont simplifié les choses? Qu'est-ce qui a mené à ce choix à l'époque? Tous les produits que vous proposez sont quand même en adéquation avec ce qu'on cherche. On a cette capacité à pouvoir créer des domaines très facilement avec votre API. Pour pouvoir accepter de nouveaux domaines sur votre réseau, vous allez pouvoir, de votre côté, créer un certificat SSL, le gérer et pouvoir le renouveler. Donc nous, on peut utiliser cette fonctionnalité, qui s'appelle SSL ForSAS. Après, il y avait également le sujet sur les workers. La plateforme de développement.

10:47 C'est ça, les workers, finalement, vous avez été une des premières plateformes à mettre ça en place pour un CDN, pour mettre de la logique. Avant, il y avait les lambdas, c'était vraiment le serverless, les lambdas qu'on peut trouver chez AWS ou d'autres choses dans le même genre, mais ce n'était pas forcément partout dans le monde. Ce n'était pas forcément les CDN qui avaient mis ça en place, donc c'était assez intéressant. Ce n'était évidemment pas facturé de la même manière, parce qu'on avait les... Il y a quelqu'un qui fait des dessins, je crois, sur le côté. Ce quelqu'un fait Tommy Dessine, qui croque. Effectivement, le problème... On n'est pas perso. Quand on rigole, c'est que c'est drôle. C'est toi, Clément, du coup. J'ai l'impression. Il y avait tout cet enjeu de récupérer le site web d'origine sur notre logique pour pouvoir utiliser le HTML et le pouvoir le remplacer en tant que proxy.

11:51 C'est quelque chose qui se prêtait exactement au design d'un CDN et pas forcément du Lambda où on est facturé sur l'entièreté de nos actions et donc évidemment aussi sur la captation de l'origine. Ok, super. Dans ce cas-là, on peut rentrer maintenant dans le livre du sujet. On a quatre grands points à vous présenter, en tout cas Nicolas va vous présenter aujourd'hui. Et le premier étant celui-ci. Je vais essayer de rentrer un peu plus dans le concret de comment est-ce qu'on a réussi à mettre en place notre solution de traduction par proxy, qui est une des solutions qu'on a pour pouvoir traduire les sites Internet. Sur un schéma assez simple, on se place vraiment entre le site qu'il y a à traduire et le navigateur, et donc on va aller répondre à toutes les requêtes. Comme je le disais, c'est bien parce qu'on a une capacité à répondre absolument ce qu'on veut quand on prend la main sur le domaine.

12:52 Ça paraît à peu près logique. En fait, on pourrait afficher n'importe quoi à la place de nos clients, mais il y a la contrepartie où... On absorbe toutes les requêtes. Donc ça, c'est quelque chose qu'on a réussi à gérer avec Cloudflare. Finalement, on n'a plus vraiment de soucis sur l'infrastructure qu'on doit avoir parce qu'ils sont capables d'absorber n'importe quelle quantité de réseau. Et puis, après, ça se profile à peu près comme ça. Il y avait un sujet de performance. Donc le Weglot Reverse Proxy qu'on voit ici, c'est le worker qu'on exécute chez Cloudflare. Il faut qu'on récupère le site web original. Donc ça prendra un certain temps, ça va être une requête HTTP. Maintenant, c'est le site qu'on aurait récupéré de manière à la base. Nous, on n'a pas vocation d'accélérer le site. Donc finalement, ça prendra le même temps que si jamais il n'était pas traduit. Mais on rajoute quand même un nouvel appel encore à cette API pour pouvoir traduire les textes.

13:53 C'est-à-dire qu'une fois qu'on a récupéré le site web d'origine, on le parse, on récupère tous les textes dans le HTML, on fait plein d'autres choses également. Mais on va aller traiter les textes assez finement pour qu'il y ait une certaine logique, un certain contexte, et les envoyer à notre API en interne. Et cette API, forcément, c'est encore un autre appel HTTP. Et donc là, on va aller rajouter des millisecondes sur le site original. C'est là où il faut qu'on essaye de s'améliorer. Nous, on est en train de travailler là-dessus. Mais le worker en lui-même, par ses le HTML, traiter toute la logique qui va se trouver dans le worker, la majorité de nos requêtes, le P50, il va être à peu près à moins de 10 millisecondes. La très grande majorité de nos requêtes vont être à peu près à moins de 20 millisecondes. Tout ça, c'est acceptable pour l'utilisateur. Mais finalement, cette requête vers l'API, il fallait vraiment qu'on l'accélère. On l'a accéléré, donc je vais vous en parler, voir comment est-ce qu'on a réussi à faire ça.

14:56 Et puis la prochaine étape, ça va être l'enlever, parce qu'en fait on peut... ne pas se permettre de rajouter 50, 60, 70 millisecondes encore en supplément parce que le site est en version traduite. Donc, si on s'attarde un petit peu plus sur l'API, en fait, c'est quelque chose qu'on a traduit, enfin, pardon, qu'on a accéléré grâce à Cloudflare. On l'a également traité avec un autre worker. Ça, c'était pas mal parce que, en fait, quand on a des applications qui sont versionnées, comme les nôtres. On a des versions, donc vous créez une première version de votre application, et puis après vous allez en créer une autre version, puis une autre, sauf qu'il y a toujours des personnes qui ne mettent pas à jour leur application. Et donc, si jamais vous voulez faire évoluer vos endpoints, vous ne pouvez pas éteindre les précédents, parce que sinon ça casserait les applications précédentes.

15:56 Ça paraît à peu près logique, je pense que tout le monde a rencontré ce problème, des applications mobiles, mais d'autres. Nous, on a un plugin WordPress, il faut que ça se mette à jour. Et si jamais les personnes ne mettent pas à jour, ils utilisent des fonctionnalités qui sont anciennes et on ne peut pas se permettre de shutdown ces fonctionnalités parce que sinon, ça ne fonctionnerait plus pour eux. Donc nous, on a cet endpoint de traduction dans lequel on envoie des textes et on récupère des traductions. Et cet endpoint, on voulait le mettre derrière un CDN, sauf que... On avait plusieurs défis, notamment le fait qu'on envoie les textes dans un body, donc c'est une méthode post, et mettre en cache sur un CDN, souvent c'est basé sur l'URL, voire même tout le temps, jusqu'ici on se base sur l'URL. Quand on veut changer le contenu d'un asset, en général on change le nom de l'URL. Et en fait, sur une méthode post, l'URL ne change pas.

16:59 C'est un peu une API GraphQL. En fait, vous avez tout le temps la même URL et donc vous ne pouvez pas mettre en cache ce genre de choses. Donc il faut se baser sur le body. Et en fait, le worker de Cloudflare nous permet de manipuler le cache. Il nous permet de manipuler le cache directement en JavaScript. On le voit ici, c'est un exemple qui est à de l'endoc, mais il est tellement proche de ce qu'on peut trouver que nous, c'est quasiment ce qu'on utilise en production. En gros, l'idée, c'est vraiment, on ouvre le cache, le cache du CDN, ça, c'est quand même plutôt bien fait, c'est assez simple, et en fait, on peut créer la clé qu'on a envie d'avoir. La clé qui va nous permettre d'identifier si jamais on est en cache ou pas, c'est nous qui décidons de ce qu'on veut mettre en cache et comment est-ce qu'on identifie le cache. Et donc là, on peut voir qu'on crée un hash du body. Et on va aller créer la cache qui, on va aller la mettre en place grâce à ce...

18:00 et on va pouvoir aller chercher la requête dans le cache si jamais on la voit ou si jamais on ne la voit pas. Si jamais on ne la voit pas, on va pouvoir aller chercher à l'origine les traductions et on pourra même faire en sorte de mettre en cache alors que la requête est déjà envoyée. C'est-à-dire qu'on n'attend pas l'action de remise en cache pour renvoyer la réponse. On voit le wait until. En gros, l'idée, c'est vraiment de... Tu mettras en cache, mais c'est pas grave, on peut continuer le script, c'est totalement asynchrone. Et donc là, c'est un worker qu'on a quasiment en production et qui marche très bien. Ça nous a permis surtout de ne pas changer l'URL de notre API de traduction et donc d'éviter de la dette. Ça nous a permis de mettre en cache des gros volumes de données parce que si jamais on avait voulu se baser sur l'URL seulement pour pouvoir mettre en cache, on n'aurait pas pu mettre tous nos textes dans l'URL.

19:04 Il y a toujours une limite, c'est souvent 8000 par exemple sur CloudFront ou des choses comme ça. Puis les navigateurs, ils ont également une limite. Donc, c'est quelque chose qu'on ne pouvait pas faire. Mais là, on a réussi à mettre ça en place et c'est vrai que ça fonctionne plutôt bien. Maintenant, on a des appels qui sont bien plus rapides et surtout, on a soulagé l'origine de notre... de notre API de traduction. Maintenant, si je reviens sur notre worker de traduction en l'UM, on avait ce premier appel à l'origine, le site original qu'on doit traduire. Donc on faisait ce premier appel HTTP. Et puis on avait cet appel à l'API de traduction. Finalement, les appels HTTP, c'est ce qui prend le plus de temps sur notre worker, ce que je disais tout à l'heure. Donc en fait, il faut qu'on... On essaye de réduire l'un et l'autre. Je disais également qu'on n'avait pas forcément besoin de réduire l'appel à l'origine, mais en fait c'est un petit peu faux, parce qu'aujourd'hui ce qu'on fait, c'est qu'on appelle l'origine,

20:15 on attend de récupérer tout le texte, tout le HTML, et puis après, une fois qu'on a tout, on le traite. Ce qui fait que c'est certain qu'on réduit la performance. En fait, on va aller réduire le temps, enfin, on va aller réduire le... Enfin, on va aller augmenter surtout, pardon. On va augmenter le temps où on reçoit le premier bit, le time to first bit. Et donc là, forcément, c'est quelque chose qui se ressent tout de suite par nos utilisateurs. Le temps final de chargement du site n'est pas forcément impacté, mais on ressent que la page ne commence pas à charger plus rapidement. En fait, on a une petite latence au début, puisque nous, on a été obligés de récupérer tout le HTML avant pour pouvoir le parser, pour pouvoir le renvoyer après au navigateur. Et donc pour ça, on est en train d'utiliser des nouvelles choses que Cloudflare a mis en place depuis un petit moment déjà. Leur API HTML Rewriter qui va permettre d'aller chercher chaque élément en streaming dans le texte. Directement, on va pouvoir récupérer les éléments, les textes, les nœuds.

21:20 On va pouvoir avoir des événements et pouvoir les manipuler en temps réel. Et surtout, les modifier au fur et à mesure de quand on est en train de lire la page. On va pouvoir les modifier et les renvoyer directement au fur et à mesure quand la page est en train de charger. Donc en fait, on ne va pas attendre d'avoir chargé toute la page de l'origine pour pouvoir commencer à renvoyer le début. Et donc pour ça, forcément, nous, ce n'est pas forcément compatible avec le design qu'on a avec notre API. Parce que notre API, on a besoin d'avoir tous les textes pour pouvoir avoir les traductions. On n'a pas envie de faire 30 appels à l'API. Je ne suis pas certain que ce soit un très bon moyen d'accélérer les choses. Et donc, on étudie également une autre solution que propose Cloudflare, c'est les KV, le système de Key Value, qui va nous permettre de stocker très simplement les traductions qu'on a envie d'avoir pour chacun des sites Internet et donc pouvoir les lire de manière très simple.

22:29 À chaque fois qu'on rencontre un texte, on va pouvoir aller changer le texte par la traduction si jamais on l'avait récupéré à l'origine, évidemment. Après, on a tout un système à mettre en place. On a un système de traduction qui sont versionnés. Donc ça, pour le coup, on est assez au courant de savoir si jamais ça a changé, si jamais vous avez changé votre traduction et qu'il faut la mettre à jour sur le site. Voilà, c'est un peu l'idée de... Concrètement, comment est-ce qu'on a réussi à mettre ça en place chez Weglot et comment est-ce que ça tourne ? C'est quelque chose qui tourne sur des dizaines de milliers de sites en production. Et puis vous pouvez très facilement voir que quand vous allez sur des sites que c'est traduit par Weglot. Enfin, j'avais un autre sujet, c'était le sujet du... J'appuie?

23:31 Ah si, j'ai trop appuyé. Le sujet du fait qu'utiliser Cloudflare nous procure un avantage quand même sympa, c'est qu'il y a pas mal de CMS qui utilisent déjà Cloudflare. Cloudflare a quand même un... Un succès auprès de pas mal de plateformes. Par exemple, Shopify. Shopify utilise Cloudflare. Ils utilisent comme nous SSL for SAS. Donc, ils délivrent les certificats SSL. À chaque fois que vous créez un domaine sur Shopify, vous allez avoir un domaine qui va se créer chez Cloudflare. En fait, si Cloudflare protège déjà Shopify, nous, si on veut traduire Shopify, alors que ça tourne déjà sur le réseau de Cloudflare, ça serait peut-être dommage de rajouter un appel. En fait, Cloudflare est compatible avec lui-même. Ça n'a pas toujours été le cas, mais maintenant c'est réglé. C'est une bonne chose de faite. Et ça peut mener vers de belles choses. Donc au final, notre... système, notre solution et puis notre logique est directement intégrée dans un réseau qui est déjà mis en place, c'est-à-dire que nos clients ont à peine besoin de changer quelque chose pour pouvoir traduire leur Shopify et d'autres CMS qui utilisent Cloudflare.

24:46 Il y a quoi? BigCommerce, Salesforce, pour en citer quelques-uns. Mais dans l'idée, c'est vraiment une capacité à pouvoir créer des solutions. un réseau qui existe déjà et qui est déjà bien utilisé. Et ça, c'est vrai que c'est quelque chose qui nous a enlevé des contraintes, parce qu'étant donné qu'on est un proxy, on va aller agréger toutes les requêtes vers un même serveur. Si jamais on n'utilisait pas Cloudflare, Par exemple, on a utilisé un serveur qu'on avait créé sur un cloud. Toutes les requêtes seraient agrégées vers la même IP et elles seraient toutes renvoyées vers le site original. Le site original, si jamais il avait un peu de sécurité, il pourrait croire que ce n'est pas trop normal parce que toutes les requêtes viennent du même endroit, donc ce n'est pas terrible. Là, Cloudflare, il protège les sites, sauf que nous, on peut directement s'intégrer dans leur système. Donc au final, c'est du gagnant-gagnant.

25:48 Puis surtout, eux, ils facturent deux fois la même requête. Donc ça, c'est quand même pas mal. Voilà, ça c'est business. Yes, ok, merci. Merci Nicolas. Du coup, c'était une utilisation assez inspirante, j'espère, et assez atypique peut-être aussi de la plateforme serverless de Cloudflare. Voilà, de notre côté, ce que je disais en introduction, on continue d'itérer sur ce réseau, sur ce edge qui est proche de chacun, tous les utilisateurs connectés à travers le monde. On va continuer d'itérer, notamment avec de l'intelligence artificielle. J'en ai entendu beaucoup parler tout à l'heure dans le... dans les pitchs d'une minute, une minute trente, qui étaient juste avant. Cette capacité aussi de toujours pouvoir bénéficier de cette plateforme que Cloudflare a créée avec ses points de présence à travers le monde et de pouvoir par exemple mettre des GPU dans nos data centers pour permettre à nos futurs clients, peut-être à Weglot aussi un jour, de pouvoir développer des applications qui embarquent de l'intelligence artificielle

26:58 et de faire en sorte que ces applications et notamment l'inférence puissent à chaque fois tourner au plus proche de là où c'est consommé. On pensait en tout cas que c'était un use case intéressant qu'on pouvait vous présenter aujourd'hui, qui était un peu atypique et qui changeait des use cases classiques autour de la performance et de la cybersécurité. Donc j'espère que ça vous a plu et on peut ouvrir aux questions. Absolument. Merci beaucoup à tous les deux. Déjà, à titre personnel, je trouve ça toujours chouette quand il y a deux personnes qui sont là pour parler d'un sujet avec deux ongles différents et qui se complètent. Ah, il y a un grand fan qui n'arrêtait pas d'applaudir. Donc je pense qu'à mon avis, il y a une poursuite de discussion. Peut-être que ce grand fan a déjà une question à poser, puisque nous avons la chance de vous avoir encore avec nous pour au moins 8 minutes, au max 8 minutes, pardon. Alors, question. Voilà. Monsieur, donc Amélie, si Amélie peut donner le micro. Je ne me suis pas trompée, c'est bien Amélie. J'essaie de retenir, ce n'est pas simple à mon âge.

28:02 Et on s'est levé tôt, ça pique. Bonjour, merci pour le talk. Ma question, elle concerne la traduction dans des langues. On peut aussi avoir des enjeux de real estate graphique ou de normes d'écriture de gauche à droite ou de haut en bas. Comment vous traitez dans le HTML justement le fait qu'il va falloir peut-être réorganiser potentiellement le HTML pour que ce soit lisible au-delà de la traduction littérale? Oui, alors pour la lecture de droite à gauche, il y a des fonctionnalités dans le navigateur qui sont déjà présentes. Donc nous, sur certaines langues, on sait qu'il va falloir le mettre en place. On le met en place automatiquement. Évidemment, ça peut casser un peu le design du site. Et donc là, en général, on va accompagner le client. En fait, on n'a pas une capacité à détecter si jamais on casse le design du site. Le navigateur essaye de faire en sorte que ça passe plutôt bien. En fait, c'est le navigateur qui gère la lecture droite à gauche. Donc voilà, je ne vais pas m'attarder là-dessus. Mais sur l'autre question, c'est pour les images, par exemple, s'il y a du texte,

29:10 C'est vraiment que pour la lecture droite à gauche, du coup? De haut en bas? Oui. En fait, c'est le navigateur qui va gérer ça. Il ne le fait pas forcément de manière... Si le site a été plutôt bien fait... Nous, c'est notre enjeu, au final, d'être compatibles avec des sites qui sont mal faits. C'est un peu notre quotidien. Donc, en fait, on apporte toujours des solutions. Mais si le site est bien fait, le navigateur a cette fonctionnalité. Il suffit de rajouter une balise qui va indiquer que le site doit être lu de droite à gauche. En fait, c'est magique, le site se retourne. Merci beaucoup Nicolas. Une autre question? Ah, au fond, monsieur, si vous voulez bien vous lever, ce serait formidable. Merci beaucoup. Merci pour la présentation. Intuitivement et peut-être naïvement, j'aurais dit qu'il faut traduire à la source, depuis le site, pour que ce soit fait une fois et qu'à tous les appels, on réutilise le même site traduit.

30:10 Pourquoi ce choix de traduire à la volée? Pour être compatible sans utilisation technique. Le but, c'est d'apporter une solution sans friction technique. Être compatible à la source, c'est bien, mais quand on utilise un CMS qui ne le permet pas, Ça ne va pas forcément être possible. Parce qu'avant, si je reste sur différents thèmes, vous prenez des CMS qui sont très utilisés, comme Shopify, Webflow, Squarespace. Ce sont des solutions qui n'ont pas forcément, du moins qui n'en avaient pas, forcément de solutions pour traduire les sites directement à la source. Mais sinon, si vous créez votre site vous-même, vous avez un développeur qui va aller développer le site de A à Z avec

31:13 un framework, avec des librairies qui sont les dernières librairies à la mode. Il vaut mieux utiliser quelque chose d'intégrer et développer son système de traduction soi-même. Ça, c'est certain. En fait, ce n'est pas vraiment notre public, les développeurs. Alors, ça peut s'intégrer sur des sites qui ont été développés, en effet. Mais en fait, le site a été développé, c'est terminé, il a été fini il y a trois ans. Et refaire appel à un développeur pour changer toute la structure du site. Parce qu'au final, on se dit, non mais c'est bon, c'est simple, il suffit de changer les textes pour pouvoir les traduire. Ce n'est pas vraiment aussi simple. Il faut souvent revoir toute la structure du site pour pouvoir arriver à faire ça. Et donc nous, on propose quelque chose de clé en main, où vraiment, en 30 secondes, on peut changer le DNS, et puis c'est réglé. Je veux dire, le site est traduit. Donc c'est plus une facilité en fait. On a choisi de ne pas apporter la brique technique.

32:17 Les briques techniques, elles existent. Il y a des solutions open source sur tous les langages. En effet, on n'espère pas concurrencer ça. Mais par exemple, traduire un Webflow il y a un an, ce n'était pas possible. On était une des solutions principales. Et en fait, on ne pouvait pas traduire la source. Il fallait créer un deuxième webflow. Il fallait créer un deuxième site. Et puis le mettre dans une autre langue. The Lang of Molière, comme le soumet Tommy, qui continue à croquer, évidemment, ce Tech.Rocks. Une autre question, éventuellement? Alors, monsieur, troisième... Enfin, je n'arrive même pas à compter les rangs. Vous êtes bien au premier rang, là? Ce n'est pas trop dur, pour le coup? Non, ça va ? L'année prochaine, ce sera empathie, le thème du Tech.Rocks. Bonjour. J'aurais voulu savoir si votre système part aussi tout ce qui est JSON, notamment dans le cas de requêtes AJAX qui retournent traditionnellement des messages d'erreur ou de succès.

33:19 Oui, bien sûr. Heureusement. JSON, XML. Pour les flux, on ne se rend pas forcément compte, mais les flux sont encore beaucoup utilisés pour mettre à jour des listes de produits sur des plateformes comme Amazon, Google Shopping, des choses comme ça. JSON, oui, parce qu'il y a énormément de sites qui sont chargés dynamiquement. On est compatible avec Wix. Wix, ça va être que du JSON. Et puis, on est compatible avec Wix. Donc, ça veut dire que franchement, déjà, là, on a bien travaillé. Super, il nous reste deux minutes pour éventuellement une autre question. Une autre question à l'autre bout. Vous avez un micro? Vous êtes venu avec? Oui, je l'ai amené. C'est Amélie qui me l'a donné. Merci pour la présentation. J'avais une question. Des fois, il y a des choses qu'on n'a peut-être pas forcément envie de traduire, qui proviennent de la base de données et qui correspondent à un nom, une marque qu'on n'a pas envie de traduire.

34:21 Et des fois, il y a peut-être du langage métier qui est très spécifique et où la traduction n'est peut-être pas forcément bonne. Est-ce qu'on peut créer des exceptions pour pouvoir ignorer certaines traductions ou en modifier certaines? Eux, la principale plus-value de Weglot, ça va être de pouvoir affiner les textes qui sont traduits, exclure des expressions, le nom de la marque, souvent qui est traduit exact, exclure des blocs qu'on n'a pas forcément traduit, exclure des pages même entières, on n'a pas forcément envie de traduire toutes les mentions légales de notre site. C'est vraiment au choix, on a des éditeurs visuels qui vont nous permettre de le faire. Le but encore, c'est vraiment une approche non technique, n'importe qui peut le faire, surtout qu'en général, celui qui sait traduire, celui qui traduit, celui qui connaît la langue, il va falloir traduire le site en allemand, en espagnol, il n'a pas forcément les compétences techniques, ou alors il n'a pas envie vraiment de travailler dans un Excel. Donc là, on apporte vraiment tous les outils pour des personnes qui ont envie de définir une traduction très fine sur le site.

35:25 Et ça se fait très simplement avec des outils qui vont agir soit sur la page qu'on voit, soit sur tout le site. Le but, c'est d'être rapide. C'est d'être efficace. On essaye d'apporter le maximum d'outils qui vont permettre de faire ça correctement. Super, merci beaucoup Nicolas et Clément, tous les deux, de nous avoir partagé ce case study différent, innovant. Et on vous retrouvera tout à l'heure à la pause déjeuner. Merci beaucoup. Absolument, merci beaucoup. Je vais partir par la gauche. Merci.