 Donc là c'est Pascal Hammerly, il va nous faire une conférence sur l'aventure de la migration et l'unification de 8 gros sites vers un seul site WordPress donc c'était des sites qui n'étaient pas et qui vont être migrés en un seul donc c'est une très grosse migration, on parle de 20 000 pages de 30 personnes travaillant sur le projet plus de 3000 heures de travail et donc il vient de Fribourg et il représente l'agence ETHOS Digital, voilà. On vous prenait des risques, parce que si c'est mauvais vous allez regretter vos applaudissements. Bon, demain juste pour le contexte donc on est ETHOS Digital, on est situé à Fribourg en Suisse-Romande mais tout près de la Suisse-Allemande. Mon associé qui s'appelle Raphaël, il est ici en noir et puis on est 5 personnes dans l'équipe de base puis on travaille aussi avec des développeurs externes, comme c'était le cas justement sur ce projet que je vais présenter aujourd'hui. Alors déjà j'aimerais commencer par la fin, est-ce que j'aurais le son si j'ai une vidéo ? Ah la vidéo ? Oui, je vais faire ça. Je commence par la fin, la fin c'est quand on avait réussi à faire le projet et ça c'était un peu la petite vidéo d'annonce qu'on a aussi publié sur nos réseaux sociaux. Je commence par la fin parce que c'est une histoire qui a bien fini, peut-être j'en parlerai pas d'ailleurs sinon. Mais c'est vrai que c'est un projet qui en cours de route a eu beaucoup d'obstacles, il était difficile au niveau technique. Et puis aussi pour expliquer comment on a développé les choses, comment on a pensé les choses, ça fait sens de montrer le résultat final pour que vous ayez un peu en tête les concepts qui ont été utilisés dans le site. Donc c'est volé, une des particularités du site c'est que dans le compton de Fribourg, si on voit un peu la carte ici, il y a cette région, donc il y a la Gruyère qui est assez connue au niveau national et international. Sinon il y a quand même Morat qui est assez connue, c'est une ville médiévale. Il y a d'autres régions un peu moins connues, la ville de Fribourg, Romon, Paco, Estavaille, Le Lac et Schwarzze, c'est un mélange entre les montagnes et le lac et la ville. Et la destination touristique de Fribourg est assez faible en Suisse par rapport à des grosses destinations comme l'Egrison, comme Genève, comme peut-être le Valais aussi. Donc ils ont vraiment voulu unifier tous les sites du compton, ils avaient 8 sites web, ils ont voulu les unifier pour avoir plus de force au niveau national et international. Et c'était aussi un projet pour le CEO en fait. Mais le défi c'est qu'ils avaient tous leurs sites web, leurs particularités locales, leurs contraintes, leurs partenaires et il fallait réussir à faire discuter en fait tous ces gens ensemble à faire un projet commun. Si vous voulez dans l'interface du site, le cœur du projet SST, si je montre un objet c'est les hôtels, ils ont des milliers d'objets touristiques. Les hôtels c'est un exemple. Et puis forcément ils voulaient l'interface, on pouvait filtrer les choses, donc peut-être par région, filtrer par style, filtrer par type d'équipement, etc. Par classification. Et puis il fallait développer toute l'intelligence dans la base de données pour pouvoir faire les appels en front-end pour pouvoir afficher les choses selon ces filtres. Et aussi la situation de départ c'est qu'ils étaient tous ces sites sur un système propriétaire. C'était un autre système de WordPress donc il fallait unifier les sites et migrer cette base de données, en fait la recréer complètement dans ce contexte de WordPress. Ça c'est un peu le contexte de départ du projet. Pour raconter un peu d'histoire, ça a commencé dans un bon restaurant parce que tout site WordPress commence dans un bon restaurant. C'est un restaurant qui est ici tout près de la gare à Fribourg qui s'appelle le Petit Pérol. Donc si on recule pour les genoux voix qui ne vont pas souvent à Fribourg, c'est ici. C'est un restaurant entre les lacs dans la partie occidentale de la Suisse. J'ai rencontré le vice directeur de l'Union Fribourgeoise du Tourisme qui a un client depuis longtemps. On travaille avec eux depuis plusieurs années. Et puis on a mangé ensemble et il m'a dit voilà on aimerait faire une stratégie pour 2022. Donc là on était en 2019 quand je l'ai vu. Et il faut qu'on élabore cette stratégie, qu'est-ce qu'on va faire avec nos données, qu'est-ce qu'on va faire avec nos points d'intérêt avec le site web, etc. Et donc il m'a dit il faut écrire un truc. Donc on a écrit un truc. J'ai écrit ça avec eux. Et ça c'était un premier rapport. Alors je ne vais pas vous montrer les rapports en détail, mais c'est déjà un document qui fait 18 pages dans lequel on présente en fait toute la stratégie et dans lequel surtout j'ai défendu une solution open source parce qu'ils avaient cette solution propriétaire. Et l'idée c'était de leur dire pourquoi ça vaut la peine d'aller sur l'open source. Et il y avait plusieurs personnes qui avaient des craintes. Donc il y avait l'office central de tourisme qui s'appelle l'Union Fribourgoise de Tourisme. Et ensuite il y avait toutes ces régions qui ont leur propre office du tourisme. Et certains directeurs, encore sept directeurs en plus, avaient des craintes par rapport à un système complètement open source. Est-ce que c'est vraiment professionnel ? Est-ce que ça va marcher ? Et donc ça c'était le point de départ. Donc après on a transformé tout ça en jolies présentations pour les convaincre. Donc les sept directeurs, j'ai passé devant eux trois fois. C'était un long processus. Il y avait des discussions. Certains ils ne voulaient pas, d'autres ils voulaient, etc. Voilà, c'était une présentation. On a discuté du contexte. On a discuté qu'est-ce que c'est propriétaire, qu'est-ce que c'est open source ? Pourquoi en fait vous êtes coincés avec vos données ? Vous ne pouvez même pas avoir l'étape des bases de données. Si c'est vos données, vous voulez faire des API. Si vous êtes dans un contexte open source, vous pourrez plus librement traiter ces données, les articuler avec d'autres systèmes, etc. Donc avec toute cette discussion, je ne vais pas entrer dans les détails ici, mais on a parlé des coûts aussi. Et puis il y avait aussi une idée, si je monte cette partie-là, de centraliser la gestion technique. Ils avaient huit sites web. Donc quand il y avait un template qui était déployé, parce qu'ils avaient les mêmes templates sur les huit, il fallait l'intégrer dans chaque site. Donc ça c'était un développeur chez eux qui le faisaient à la main. Mais c'était long. Un changement, il fallait pour mettre en prod. C'était un long processus en fait. Donc ça c'est un peu le point de départ. Après, on s'est dit maintenant, pour valider le projet, il faut faire une structure du site. Donc on a fait des workshops avec plusieurs membres de ces régions. On a fait, je pense, deux workshops. Puis on est arrivé à ce premier résultat ici, qui est un résultat qui nous a permis de structurer tout le contenu qu'ils ont sur le site. Je prends une toute petite section, par exemple vélo-lvtt. C'est une thématique importante pour eux. Donc ils ont des itinéraires cyclistes, des tours à vélo, des itinéraires vtt, des bike parks, etc. Donc pour chaque élément, pour chaque type d'objet, il fallait structurer comment on allait faire un menu, et comment on allait faire aussi les profondeurs des pages dans le site WordPress. Ça c'était une étape qui a duré deux mois. Enfin workshop, discussion, etc. Ensuite, on est passé à l'étape des wireframes. Ça c'est mon associé Raphaël qui s'occupe de ça. Et là, de nouveau, c'était d'essayer de les projeter dans qu'est-ce que ça allait donner au niveau structurel. Donc on a imaginé, on garde ici le logo principal de tout le contenu. On a commencé à travailler sur les menus, sur la structuration des pages, avec des blocs tendances pour mettre en avant une carte qui explique le concept du site avec les différentes régions, différents modules qui permettait d'appeler les objets, de les présenter dans des contextes de landing page. C'est là que Raphaël a un coup de génie, parce qu'il trouvait tous quand même que ce logo de Fribourg région qui était en haut trônait de manière trop puissante face aux régions, aux sous-régions si vous voulez. Donc Raphaël l'a dit, on va leur faire un branding où il y a des sous-cites. Si je suis dans la gruyère, je vois le logo de la gruyère. Si je suis dans le morage, je vois le logo de morage. Donc on a vraiment conçu tout le site avec une segmentation profonde, avec un code de couleur, pour que chaque région puisse y retrouver et que le trafic et la tir vers ses pages, notamment par les références naturelles, arrivent toujours chez elle, si vous voulez. On puisse montrer que le projet allait à la fois intégrer cette dimension régionale et aussi l'aspect cantonal du site. Donc si vous voulez qu'on se reflète dans le site final, c'est qu'ici je peux naviguer entre les régions, si je vais par exemple ici dans FreeBourgVille, ou bien ici je peux revenir à l'échelle de tout le canton. Et si je reprends l'exemple des hôtels, ici j'aurai un listing avec tous les hôtels qu'ils ont bien voulu mettre dans leur listing, donc il y en a 125. Mais ici j'ai un code couleur, c'est à l'orange, c'est à travailler par exemple, mais je pourrais maintenant aller dans une sous-région, ça serait FreeBourgVille. Et puis si je vais aller dans un objet spécifique, je change en fait de logo en haut et puis je vais arriver dans la partie de cette région. Voilà, donc ça c'est le logo spécifique de cette région. Donc il y avait vraiment cette idée comment présenter à l'utilisateur l'interface pour qu'ils comprennent qu'il y a ces deux niveaux et ces deux dimensions. Donc en novembre 2020, le projet a été validé par tous les directeurs et on a décidé d'aller de l'avant. Puis c'est là qu'on s'est assis et qu'on s'est dit ok mais comment on va faire tout ça maintenant parce que c'est 8 sites web qu'il faut migrer sur WordPress. On change de système. Il y avait 8 bases de données segmentées. En plus on n'avait pas accès aux tables. Comme j'ai dit avant, c'était juste les JSON qu'on avait à travers une API. Donc c'était pas des données qui sont structurées dans leur profondeur avec les connexions des tables. C'était vraiment un peu des données à plat qu'il fallait reconstituer et repenser. C'est un site multilingue, bien sûr. Il y avait ces questions de filtres compliquées et il y avait surtout l'idée qu'il voulait un back office d'édition qui permette d'éditer ces objets qui existaient déjà. Donc on a écrit un document. Je vais pas l'ouvrir mais avec toutes les specs du projet. Donc ça c'était de nouveau de la rédaction écrite avec plusieurs personnes dans le Google Docs. Et puis après on a fait ce petit document là aussi qui est intéressant. C'était un document qui montrait un peu tous les flux donnés finalement vers le site. Donc ici j'ai le site WordPress lui-même. Il avait des API en 30 pour la météo, pour point firmice, pour la météo des plages et puis des flux de webcam. Mais il avait aussi des API sortantes vers des systèmes de réservation d'offres. Smith et puis Treksoft. Enfin ça c'est de l'intégration HTML. Et puis Vulkan, ça c'est pour les newsletter. Et après ici la base de données objets. Donc ces objets qui existaient déjà. Eux-mêmes ils étaient connectés avec des écrans physiques d'information qui sont dans les offices du tourisme. Ils étaient connectés avec Guidel qui allait vers Swiss Tourisme. C'est le site national du tourisme. Et donc il fallait aussi que cette base de données puisse facilement être traduisible en flux API qui vont vers ces différents systèmes. Voilà, j'aimerais juste maintenant bien expliquer les objets parce que c'est vraiment le cœur du projet. Si je prends un hôtel ici, bon il a un titre. Il part un nombre d'étoiles. Ça c'est un attribut. Il peut avoir une adresse. Des liens externes. Il peut avoir des tarifs. Et les tarifs, il y avait aussi des questions de traduction. Par exemple si dans le back office on met 115 francs pour la chambre, on veut que ça se reflète directement en allemand en anglais. Mais par contre le label de la chambre, il faut pouvoir le traduire à la main. Ça c'était assez compliqué dans la base de données. Par exemple avec VPML, on a essayé au début mais ça ne marchait pas en fait parce qu'il fallait vraiment trop segmenter l'information et puis l'utiliser de manière très flexible. Donc on a complètement abandonné ensuite VPML pour ce qu'il y ait des objets. On l'a gardé pour la partie gestion des URL, du front, mais pas pour les objets. Donc maintenant il faut imaginer que tous ces objets, en fait, il y a plein de types d'objets. Donc il y a des hôtels, il y a des itinéraires, il y a des contacts, il y a des événements. C'était chaque fois des types d'objets aussi custom qu'il fallait penser en fonction de ces champs. Et là on a travaillé dans des Google Sheets. Bon, c'est peut-être un peu petit. Mais en gros, si vous voulez, Chaque Lean, c'est un type de champ. C'est déjà grandi un peu. Donc ok, il y a un Summary, qui est multilink, qui est un TextArea, où il y a une description, qui est multilink, c'est du HTML. Et là on a vraiment tout documenté, tous les champs qu'il y avait et le type de données, comment les stocker ensuite dans la base de données. Ça, ça a pris énormément de temps à faire. C'était une longue discussion avec le client, parce qu'ils voulaient garder leurs données, mais ils voulaient améliorer leur système aussi, puisqu'on refusait tout. Et c'était beaucoup de va-et-vient avec la chef de projet à côté client, plus derrière, avec les régions qui devaient revalider encore. Donc en termes de gestion de projet, c'était des rythmes assez lent. On avait des séances mensuelles avec toutes les régions, puis avec les services de projet, ça c'était constant. Même vers la fin du projet, elle venait un jour par semaine, elle était dans mon bureau en fait. Leur développeur à eux, il était aussi deux jours par semaine dans notre bureau, parce qu'à la fin, il fallait avancer plus vite. Voilà, après, il y avait un autre aspect difficile, c'était les URL, parce qu'il fallait que tout ça s'ajoute. Et puis là, c'est un peu l'aspect où on a vraiment eu plus de problèmes au niveau technique, avec WordPress, parce qu'on a poussé la chose très loin aussi, parce qu'ils avaient forcément tous un slug qui finit par slash randonner, ou slash telle chose. Et puis, si on utilise le chemin, enfin l'arboréissance de l'URL par défaut WordPress, il prend que le slug, et donc on avait des conflits, puis quand on avait migré les données, donc les fameuses 20 000 objets, ça va créer plein de tirs et deux, tirs et trois, tirs et quatre. Et après, on a dû travailler beaucoup dans la base de données pour tout clarifier. Et quand on faisait ça en même temps, dans un site de pré-prod, où déjà les gens avaient commencé à mettre des pages TMS, c'était assez amusant comme vous pouvez imaginer. Ça, c'était des moments un petit peu compliqués avec les URL. Donc on a, si vous voulez, il y a un schéma d'URL où chaque région dans les trois langues, elle a sa partie d'URL qui va aussi appeler le template, qui appelle le logo brandé de la région. Donc ça, c'était toute cette structure. Bien sûr, parce que ce n'est pas trop simple. Il y avait plein de catégories d'objets, puis il y avait des ID dans l'ancien système, et puis il y avait plein de langues, enfin les trois langues. Donc ça aussi, il fallait créer toute une structure d'URL qui permet de supporter ça. Si je vous montre juste un exemple, si je reprends un hotel, si je prends un hotel spécifique, lui, il va être dans Fribo-Ragion, ça, c'est tout le site, dans la destination Estavaille et Payern, dont je retrouve le logo ici, dans la catégorie Hôtel. Et maintenant, c'est un objet spécifique. Et ça, en fait, c'est niveau de profondeur. On voulait les faire parce que c'est bien pour lui, d'avoir le breadcrumb. Et aussi pour que les gens s'orientent dans le site, mais aussi pour le SEO, c'est bien d'avoir des niveaux de profondeur. Au niveau technique, ça, c'était vraiment la chose la plus complexe du site. On a dû le faire et on a dû se surprendre pas mal de fois pour trouver des bonnes solutions. On a utilisé un plugin qui s'appelle Permalink Manager, mais après, en fait, Vortepresse gardait ses slugs natifs derrière et, des fois, ça créait des conflits. C'était assez complexe. Voilà. Puis, c'est là que j'ai eu le téléphone avec Cyril Brom, qui est aussi ici et qui a parlé ce matin. Je lui ai raconté tout ce qu'on devait faire avec ce projet. Puis, pendant le projet, il s'est marré. Puis, il a dit, il y a des gens qui ont un talent fou pour se mettre dans des galères impossibles. Il y avait plein de pistes. Donc, on est partis un peu en vrille dans plein de solutions. Donc, tout le front, on savait que ce serait du WordPress, mais le Backoffice, c'était pas encore décidé à ce stade. Et puis, une des idées, c'était de faire une Google Sheet connectée au site. Ensuite, on a parlé d'utiliser du Laravel pour le Backoffice connecté à un WordPress. Il y a Lausanne Tourisme qui a fait ça. On savait qu'ils avaient réussi. Après, mon associé, il pensait que Drupal, c'était quand même mieux pour faire un site dans lequel le WordPress commence. Donc, il a peu près, je pense, 18 ans d'expérience. Lui, il m'a dit, moi, je le fais pas. Et après, j'ai dit, je fais juste le front. Je fais le HTML, mais le Backoffice, ça m'intéresse pas trop de faire ça parce qu'au fait, il y aurait des problèmes avec les URLs. Il avait flairé le truc depuis le début. Donc, après, j'ai un grand moment de solitude parce que le temps avancé, je vais vous montrer la timeline après, mais on était déjà vers la fin plus tard, plus tard, 2021, parce qu'ils étaient sur une solution propriétaire dont le contrat, 5 ans, arrivait à terme. Donc, c'était une vraie deadline. C'était pas une deadline, on dit, on va prendre 3 mois de plus. Il y avait cette pression de la deadline. Et puis, à cette échelle-là, quand je trouvais pas des développeurs supplémentaires que mon lead développeur me disait, oui, moi, je te fais le front, il n'y a pas de problème, mais le Backoffice, c'est trop compliqué. J'ai un moment de solitude difficile. C'est quand même gros, ce projet, c'est quand même plus gros que ce qu'on a pensé au début. Donc, le budget, on peut l'augmenter, mais il y a quand même une sorte de limite. Donc, on négocie un petit peu sur tout ça. Et puis, on a dit au cas, on va outsourcer. Et puis, on va vous faire des prix plus bas que nos prix normaux. Mais on va outsourcer vers d'autres pays pour les développeurs. On a commencé avec l'un d'en fait. Et ça, ça durait 100 heures de travail pour moi de comparer, trouver les critères, où ça n'a pas marché, la deuxième série de développeurs, où ça n'a pas marché, la troisième, où ça n'a pas marché non plus. Et là, c'était difficile. Après, on s'est dit, ok, on va changer stratégie, on va aller sur l'Europe de l'Est. Et on a trouvé une agence, c'est des Ukrainiens, mais ils sont au Pologne en fait. Voilà. Et puis, là tout de suite, quand on les a rencontrés, déjà ils comprenaient qu'on leur parlait très clairement et ils avaient aussi une attitude plus proactive. Donc, on a vraiment pu les intégrer dans le projet. Peut-être si j'ai le temps, les outils qu'on a utilisé, on l'utilise notamment Monday, je ne sais pas si vous connaissez. Ça, je vous montre juste ça. Ça montre un peu une vision du projet. Et dans Monday, on avait deux couches. On avait une vue avec les détails, en fait. Et puis, une chose qu'on a appelée la macro timeline. Donc, si vous voulez, par exemple, ça, c'est la partie front-end, ben, il y avait le... tout est vert, justement maintenant. Mais pendant longtemps, il y avait la partie design, le HTML, le concept des pages TMS, etc., il y a tout ça. Après, il y avait toute la partie back-end avec la base de données puis avec ce back-office. Et puis, il y a plein de choses qui dépendent d'autres choses. Ça veut dire, il faut finir ça pour passer à ça, mais en même temps, il faut avancer sur ça parce qu'il ne le sera en retard. Et c'est vrai que c'était vraiment intéressant, en fait, de suivre ce projet. Et la relation avec le client était très, très bonne, en fait, parce que oui, c'était une petite et la chef de projet, sans elle, en fait, le projet n'aura pas pu réussir parce qu'elle a beaucoup pris les feedbacks des régions puis elle nous les ramenait chez nous. Voilà. Après, je vous montre le premier schéma du concept. J'ai combien de temps, encore, parce que j'ai pas une conscience claire de quand j'ai commencé, en fait, le problème t'écout. Encore 10 minutes. Ah, ici, ok. Donc ça, c'était le premier gris bouillis qu'on a fait avec le lead developer. Il a dit, donc après, on l'a mis au propre parce que ça, c'était pas... Attendez, j'ai fermé... j'ai fermé... j'ai fermé... j'ai fermé la main pendant... euh... j'étais... un peu plus bas. Voilà. Ici, on a fait une version au propre. Ça, je vais m'expliquer un peu, pour ceux qui sont plus orientés techniques. Donc si vous voulez, il y avait l'idée que tout va l'être dans la base de dernier PHP MyAdmin classique WordPress, mais on a utilisé la partie native d'ABS, forcément, avec des blogs Githambler Customs. On a utilisé un plugin qui s'appelle Metabox pour les développer. Mais après, pour la base de données, on l'a complètement fait sur mesure parce que ces objets, j'ai pas scrollé dans la Google Sheet, mais le POI, il a 80 champs, par exemple. Donc, c'est compliqué comme structure. Le faire ça tout avec un plugin comme ACF ou Metabox, c'est très compliqué. Et en fait, on a séparé ces tables. Elles sont dans le même environnement, avec VPML pour la publication, le sélecteur de langues et la corrélation des URL, mais tous les contenus qui sont dans l'objet, ils sont dans des tables qu'on a créées complètement sur mesure. Et ça, c'était aussi un travail intéressant de merger ça, de faire que ces choses fonctionnent. Et là, il y avait le back-office pour les objets. Je vais vous le montrer juste après. Il y avait un peu le concept de front-object. Ça voulait dire, on construit l'objet à partir des données qu'on prend dans la base de données. On met encore la couche d'HTML-CSS pour afficher ce front-object qu'on a tiré de la base de données. Ça fait cette connexion entre les deux. Plus, il y avait ces questions d'API qui devaient se connecter avec ces tables. Bon, après, on a fait un cas des charges. Je vais pas l'ouvrir parce que ça prend un peu trop de temps. Sur les outils qu'on a utilisés, c'est Monday. Donc, on avait aussi un board DEF qui est plus ou moins fini parce qu'on a aussi la chef de travail. La chef de projet client, elle était là-dedans. Ça, c'est le développeur et son chat. Donc, il vit d'ailleurs sur une île qui s'appelle Majorc. Il vit dans une sorte de concept un peu écollo avec des panneaux solaires sur son toit, des batteries pour pouvoir le travailler avec nous, son interruption, etc. Et je le vois. Donc, voilà. On bat un Google Drive. On a utilisé beaucoup Google Drive. Et puis aussi telegram, si vous connaissez, ça ressemble peut-être un peu à WhatsApp. Il y avait un groupe avec les régions et un groupe avec le client. Et ça, ça a vraiment permis beaucoup de transparence dans la communication parce qu'il n'y avait pas des gens qui sont voyés des emails et on perdait le fil. Il y avait tout qui était centralisé sur des groupes. On pouvait voir toutes les communications. Après, sur le design du front, ce qu'on avait fait parce qu'on devait avancer sur le front plutôt en travaillant sur les données, c'est qu'on leur a fait une sorte d'installation comme ça. Ça, c'est juste du HTML, comme j'expliquais, c'était des processus assez longs. Donc, on leur livrait ça, c'était déjà responsive, en fait, ces templates. Mais c'était statique, mais ça leur montrait comment les modules allaient fonctionner. Et bien ça, il y avait la page d'État, EPOI, ténéré, réveillement, webcam, etc. Et puis ça, on a pu tout valider en parallèle qu'on structurait justement cette base de données. Je n'ai peut-être pas étroit dans les détails. Je vais s'expliquer ça par orale par exemple. Par exemple, pour la homepage, on a fait les modules dans Gutenberg, enfin, dans l'éditeur maintenant par défaut de WordPress, avec des blocs custom qu'on pouvait appeler, qu'on pouvait redonner dans les landing pages de chaque région. Plus, on a pris les blocs qui existaient et on a encore ajouté des blocs pour faire des campagnes ou des pages spéciales. Donc, on a vraiment resté dans le native WordPress. Pour toute la partie où WordPress est excellent et où c'est qu'il y avait ces pages CMS qui rentraient dans ce cadre là en fait. Du backend, je vais montrer ça justement. Bon ça, j'ai un petit peu raconté déjà. Donc, j'aimerais vous montrer le back office. Attendez. Je vais juste montrer la structure des données encore. On a fait aussi un site de formation WordPress avec des tutos pour aider l'utilisateur à prendre en main le site. Voilà, c'est ça que j'aimerais vous montrer. Non, c'était ce que j'ai déjà ouvert avant. C'était ça. Pardon. Voilà, c'était ça ici. Il y a un site qui s'appelle Lucid où on peut créer des schémas de base de données en fait. Voilà, ça ressemble à ça. En fait, c'était vraiment toute la structure des tables, donc ces tables custom qu'on a créées. Et puis, on a identifié justement tous les champs. Il y avait des liens. Donc, typiquement, l'objet POI qui pouvait être un hôtel. Pour prendre cet exemple là, il était connecté avec un contact qu'un autre objet pour les POI. Il y avait des galeries d'images, etc. Donc, on a structuré tout ça et ça, c'était un travail assez long aussi, de penser comment bien structurer les données. À partir de ces données, Jason, qui était assez à plat et dont on avait pas la structure profonde. Ensuite, on a travaillé sur ce back-office. Et puis, ça, c'est un peu peut-être la chose que je voulais dire aujourd'hui. Même pour un projet complexe, en fait, on peut très bien développer des choses sur la base de WordPress et ça peut marcher très bien, en fait. Donc, si je montre un exemple avec un hôtel, peut-être, on met un peu des anglais. Ok. Donc là, c'est le back-office. Là, il y a toute une série d'objets custom. Si je prends les points d'intérêt qui sont peut-être l'objet le plus compliqué, je prends un test, je vois qu'il y a un test ici. Comme ça, je peux jouer avec sans casser le site web. Donc, on a le titre. Ici, il y a un hôtel parce qu'on avait ces problèmes où ça se marchait dessus. Donc, on a tout caché le slug de Yoast, le slug de WordPress, puis on a mis un autre. Et on a vérifié que quand on sauve, ça mettait tout à la bonne place parce qu'il y a pas mal de problèmes avec ça, justement. Puis ici, on a fait ce back-office. Donc, ce back-office, il a une tête de WordPress quand on le voit. Enfin, il a l'air d'être normal. Mais il est complètement fait sur mesure. Raphael, il a fait des maquettes du back-office. Après, on a tout créé ça, en fait, complètement sur mesure. Mais c'est intégré dans WordPress. Donc, le client, il a l'avantage qu'il a tout dans la même interface. Avant, ils avaient deux interfaces. Une pour le CMS, une pour les objets. Et maintenant, il y a tout qui est ensemble ici. Donc, par exemple, ici, on peut connecter avec des contacts. Donc, on peut trouver un contact et ça le connecte. On peut mettre des liens. Ici, dans les heures d'ouverture, on peut créer des périodes. Et puis, on peut poser des périodes classiques. On peut répéter la période chaque année ou pas. Et puis, on peut créer ses horaires. Ici, aussi pour les tarifs, justement, ça, c'était avec les langues. Là, les langues, cette partie-là, des langues, c'est séparé dans nos tabs Custom. Ce n'est pas dans VPNL, en fait. Parce que, comme on devait avoir des éléments, comme par exemple, OK, enfants, ça, en allemand, c'est kind, il y a 4 fois. Donc, si je passe dans l'allemand, ici, le prix va rester. Mais ça, par contre, je l'ai plus. Donc, l'utilisateur peut, à la fois, gagner du temps en gardant le prix, parce que ça, il ne veut pas le définir 14 fois. Mais, on peut quand même traduire la partie qui est traduisible. Et ça, c'était pas mal de travail, mais c'était intéressant de développer cette partie-là. Après, ils ont tous les objets. Là, c'est un exemple. Donc, on peut aussi lier des objets. Ça veut dire, si je suis à tel endroit, on propose après sur le front d'autres choses qui sont proches de où je suis. Prenons, par exemple, ça. Donc là, c'est un objet qui est rempli. Ici, je peux naviguer dans les langues. Je pense qu'ils ont des prix. Là, par exemple, ils ont toute leur série de prix. Ici aussi, on peut faire du drag-and-drop pour changer le positionnement sur le front-end. Ici, on peut lier des objets. Bon, puis après, encore des attributs qui sont applicable, qui correspondent à ce qu'on utilise dans les filtres. Ça, c'est une taxonomie. C'est autre chose que la catégorie d'objets. Est-ce qu'il a du wifi? Est-ce que c'est un appartement? Est-ce que c'est trois étoiles, l'hôtel? Je ne sais pas quoi. Ça permet d'utiliser ces filtres après pour se retrouver dans le site web. Voilà, tout à la fin du projet, en fait, c'était compliqué parce qu'ils ont quand même dit qu'ils voulaient pas mettre le site en ligne le 31 décembre. On avait prévu de commencer au 13 décembre et après, il y avait la chef de projet. Elle a dit j'ai des vacances et je suis en train de mourir, donc je vais pas en vacances le 15. Donc après, sinon, plus le vis-à-vis côté client, c'était quand même aussi nécessaire de finir. Donc le 15, on a commencé la mise en ligne et en fait, les régions, ils n'avaient encore pas fini tous leurs home page parce qu'on leur avait mis les modules à disposition peut-être dix jours avant quand on les avait finis. Enfin, à la fin, ça se resserrait comme ça. Des passés, ils n'arrivaient pas. Il y avait en cours deux personnes chez nous à l'interne qui leur lisait les textes et puis en même temps, on essayait de corriger les problèmes du réel. Donc à la fin, ça s'est vraiment beaucoup resserré. Et puis ici, si je vais dans telegramme, par exemple, ici, on avait ce groupe avec les régions. Là, je suis le 10 décembre. Je pense que je vais arriver là sur le 13. Donc là, on a commencé la mise en ligne. Ça, c'est le 13 décembre. Maintenant, c'est avec les régions. On a dormi au bureau. Et ça, c'est juste un des trois chats. Là, je suis le 15. Voilà. Donc à la fin, c'était extrêmement intense. Bon, c'était aussi sympathique parce qu'il y a aussi un côté adrédaline qui est sympa. Mais il y avait beaucoup d'interactions avec les retours qui venaient des clients. Il y avait encore la fin du développement. Et puis le 14 vers 2h du matin. Enfin, ça a duré. La mise en ligne, c'était beaucoup, on compte, mais c'était plus que 24 heures, finalement. Parce qu'après, on a aussi dû encore faire des corrections parce que ça, c'était encore la nuit. Et puis après, vers 2h du matin, on avait tout redirigé les DNS qui étaient aussi une assez grosse affaire. Parce qu'il fallait rediriger tous les nombres de domaine. On les avait tous récupérés, le contrôle à l'avant, c'est tout ça. Et puis après, voilà, ça a marché. Le site était en ligne et tout le monde a pu dormir tranquille. Mais je pense que je suis à la fin du temps aussi. Donc... Non, je peux m'arrêter là. Enfin, il y a plein de points qu'on peut explorer. On est arrivés au bout du temps. Effectivement, c'est un sujet très long et très passionnant. Est-ce que vous auriez des questions ? Oui, j'arrive. Oui, merci. C'était super intéressant. Alors, je sais que je suis sur un World Camp, mais est-ce que avec le recul, finalement, World Press, c'était le bon outil ? Bien sûr. Absolument. C'est ça. Le message fondamental, c'est que en fait, World Press, il comprend un grand nombre de fonctionnalités de base et ils vont pouvoir faire des fonctionnalités qui existent dans World Press. Donc après, on peut les retoucher, les améliorer, mais eux, pour le développement, avant, dans le système propriétaire dans lequel ils étaient, quand ils voulaient faire un changement, il fallait tout que cet agence-là qui avait son propre outil, développe elle et donc le financement, il devait financer tout le développement de la fonctionnalité. Une fois, ils voulaient faire un peu du commerce en ligne, il fallait créer le module de commerce en ligne. Enfin, genre, vous créez mais quand même, maintenant, d'ajouter beaucoup de fonctionnalités. Aussi, il y a quand même beaucoup de systèmes qui sont intégrables avec des plugins directement dans World Press. Donc je pense que là, ils ont une base qui est très bonne. Alors peut-être un développeur de Roupal, il va m'expliquer pourquoi ça aurait été plus simple en Roupal, mais voilà. C'était un peu ma naïveté en fontine, peut-être, de me dire qu'on m'avait toujours dit qu'on pouvait tout faire sur World Press. Donc maintenant, je ne trouvais pas mes développeurs l'été. Mais disons, à la fin, ça a marché et puis, bien sûr, ça aurait pu être fait dans un autre contexte. Je ne dis pas que c'était le seul possible. Super. Merci. On n'a plus de temps pour de questions. Je suis désolé. Par contre, il est disponible. Il ne s'en va pas tout de suite. Donc vous allez pouvoir lui poser les questions. Et donc on l'applaudit encore une fois. Merci beaucoup Pascal.