La DT de Meetic
|
Equipe
|
10 personnes |
Services
|
Développements spécifiques
(pour la plupart). |
Langages
|
C et PHP. |
Serveurs
Web
|
- Zeus:
gestion des pages dynamiques,
- Tricks (Red Hat):
gestion des pages statiques,
- Apache: gestion des flux entre les
serveurs Audiotel et Web (Web Services).
|
Bases
de données
|
Oracle et mySQL |
OS
|
Linux (Red Hat) |
Mobilité
|
WAP, Imode et SMS. |
Hébergement
|
LDCom (serveurs dédiés) |
JDNet Solutions Quelles sont
les principales problématiques fonctionnelles des sites de Meetic ?
Emmanuel Prevost.
Meetic offre d'abord des services d'inscription et de consultation. Mais également
des systèmes de recherche de profils (simple et avancé) avec la
possibilité de croiser plusieurs critères liés à l'abonné
- tels que la date de naissance ou la zone d'habitation. Ces dispositifs sont
complétés par deux outils de communication proposés aux membres
pour rentrer en contact: une messagerie instantanée d'une part, un environnement
d'échange de mail d'autre part.
Le back office du site se compose d'un workflow de modération des
annonces (textes, photos, etc.) doublé d'un mécanisme de surveillance
visant à traquer les comportements anormaux - c'est-à-dire les insultes
et autres actions indésirables.
Entre
développements spécifiques et solutions du marché, que privilégiez-vous ?
Sur ce point, nous n'avons pas de religion. Les décisions sont
prises en fonction des projets et des problématiques. Il est vrai que la plupart
des composants mis en oeuvre sur nos sites ont été développés ici. C'est le cas
de notre plate-forme de paiement. Elle devait pouvoir proposer plusieurs options
: un paiement à la minute - en s'adossant à des connexions par modem ou audiotel
-, une offre par abonnement, et un mode de versement par action réalisée. Or,
lorsque le site a été élaboré (en 2001), il n'existait
pas de produit capable de gérer des opérations de micro paiements comme nous l'envisagions.
Mais dans d'autres domaines, il nous arrive de faire appel à une technologie
du marché. Pour nos besoins en matière de reporting par exemple,
nous avons trouvé un produit qui correspondait parfaitement à nos enjeux.
Nous avons par conséquent jugé qu'un développement interne
ne valait pas le coût. Cet applicatif nous permet notamment d'assurer le
suivi de l'activité du site (taux de recrutement par campagne, comportement
des visiteurs, etc.).
Quelle est votre position vis-à-vis de l'Open
Source ?
Là encore, tout dépend des situations. Nous avons
par exemple décidé de conserver nos applications de chat sous la
base de données MySQL, car elle suffisait largement pour ce périmètre
fonctionnel.
Plus généralement, nous tentons de tirer partie des logiciels Open
Sources, quand cela est possible, pour accélérer nos développements
spécifiques. Prenons le cas de notre messagerie instantanée: nous
l'avons élaborée à partir d'un moteur Open Source (Jabber).
Cette première base a grandement facilité notre travail de mise
en oeuvre. Nous avons eu tout loisir d'adapter ce noyau à nos besoins en
créant nos propres composants. Notre principal enjeu consistait notamment
à intégrer pleinement ce service à l'interface Web du site,
et éviter ainsi tout écran spécifique... avec pour objectif
final de n'exclure aucun internaute.
Vous mettez en oeuvre une stratégie multi-canal ?
Nos serveurs sont effectivement couplés à une plate-forme
multicanal. Elle nous permet par exemple de donner accès à nos services
de consultation de profils et de messagerie instantanée par le biais des
SMS. Nous publions également des versions de notre site Web adaptées
aux terminaux WAP et Imode. Enfin, nos abonnés ont la possibilité
de transmettre des messages vocaux en se connectant à notre application
Audiotel. Notez que cette plate-forme a également donné lieu à
un développement maison.
Comment gérez-vous
l'hébergement
?
Nous avons opté pour un hébergement lourd (chez LDCom).
Le montage matériel et applicatif de nos serveurs a été réalisé
par nos soins. Nous réalisons également l'exploitation et la maintenance
de notre environnement en direct. Le choix d'internaliser ces tâches est
préférable pour nous dans la mesure où notre configuration
est très spécifique. Il serait très difficile d'appliquer
des procédures d'exploitation classiques. Cette méthode nous permet
en outre d'être réactif en cas de nécessité.
Et la montée en charge ?
Nous gérons jusqu'à 3500 messages par minute, et
quelque 190 000 visiteurs uniques par jour. Ces niveaux de fréquentation
impliquent la mise en oeuvre d'une architecture haute performance. Ainsi, nous
doublons l'ensemble de nos composants Web. Nous disposons par ailleurs de grappes
de serveurs internes à la plate-forme, en vue de supporter des systèmes
de cache ou pour notre base de données principale (Oracle).
Nous sommes entrain de renforcer la robustesse de cette infrastructure. Nous comptons
notamment mettre en production un centre de données tiers pour les opérations
de sauvegarde. Il s'agit aussi de consolider nos composants, en évoluant
vers une architecture où chaque champs fonctionnel serait associé
à son propre serveur d'applications (messagerie, etc.).