Tripadvisor (TheFork) : de Symfony/SolR à la reco IA hybride.

TheFork (filiale Tripadvisor depuis 2014). Plateforme de reservation resto europeenne, des dizaines de millions d'utilisateurs, des dizaines de milliers de restaurants partenaires. La promesse : trouver le bon resto au bon moment, et y reserver en deux clics. Notre travail : le pipeline qui rend cette promesse tenable.

Le point de depart (2017-2018)

Racem integre cote arriere-plan resto-tech. Pile initiale : Symfony 3 + Node.js + RabbitMQ pour la messagerie asynchrone + SolR pour la recherche. Mandat : tenir la charge sur les pointes de reservation du soir et de la fin de semaine, et faire evoluer le moteur de recherche au-dela du simple appariement nom + ville.

Ce qui a ete livre

• Index SolR optimise pour la recherche restaurants (geo, cuisine, dispo en temps reel, prix moyen)
• Travailleurs RabbitMQ pour le traitement asynchrone des reservations, notifications, sync caisse partenaires
• Refactorisation de l'arriere Symfony : extraction de bounded contexts (reservation, catalogue, fidelite, avis)
• Observabilite et profilage : reduction de la p95 sur les points de terminaison critiques
• Documentation des conventions de code et integration des developpeurs juniors arrivants

La pile qu'on deploie aujourd'hui

Sur le meme metier (recherche resto, recommandation personnalisee, conversion sur creneau dispo), voici ce qu'on assemble aujourd'hui :

• Algolia comme moteur de recherche principal : geo, facettage, tolerance aux fautes de frappe, latence sub-100ms cote edge
• Plongements Mistral 7B sur les fiches resto et les avis : recherche semantique 'dimanche midi en famille avec terrasse calme'
• pgvector pour stocker les plongements et profiler par utilisateur (preferences cuisine, prix, ambiance)
• Moteur de recommandation hybride : filtrage collaboratif + LLM-augmente (Claude Sonnet en re-classeur sur le top 50)
• Apache Kafka comme bus d'evenements (reservation, no-show, annulations, sync caisse) avec relecture sur incident
• Datadog en pile complete : APM + RUM + journaux structures + alertes de garde fin de semaine / soir

Pourquoi c'est exigeant

• Latence : un utilisateur a moins de 800 ms d'attention avant de defiler. Recherche edge non-negociable
• Pointe horaire : 19-21h en semaine, x4 du QPS moyen, et personne ne pardonne une indisponibilite a 19h45 un samedi soir
• Donnees resto bruyantes : menus changeants, fermetures imprevues, photos perimees
• Demarrage a froid utilisateur : un nouveau venu n'a pas d'historique, mais doit avoir une recommandation pertinente en 2 ecrans
• Conformite LPRPDE sur les profils plongements : duree de conservation, droit a l'oubli, retrait recommandation

Ce que ce mandat a appris a Abbeal

TheFork a ete notre premier mandat serieux sur une place de marche a haute frequence. On y a appris a optimiser le SolR de l'epoque, puis a passer a Algolia + plongements sans casser l'EDS, et surtout : qu'un moteur de recommandation mediocre peut couter 5 a 10% de la VBM en silence. C'est ce qu'on rejoue aujourd'hui chez les autres places de marche resto / loisirs / voyage qui basculent sur du classement LLM-augmente.