Revue de presse

Interview de Stanislas Di Vittorio

Publié par le , Mis à jour le 08/12/2010 à 14:12 , Source : Journal du Net
JDN Solutions. Quel est le métier d'Assurland et comment fonctionne sa direction informatique ?
Stanislas Di Vittorio. Assurland est une société créée début 2001. Elle fait de la comparaison d'offres d'assurance en ligne pour les particuliers. A la manière de Kelkoo, nous ne vendons pas de produit mais renvoyons l'internaute vers les sites de sociétés tierces. Une vingtaine de personnes travaille pour Assurland et l'équipe technique regroupe six collaborateurs.

Quelles tâches avez-vous confiées à votre hébergeur ?
Notre hébergeur, Colt, est aussi notre fournisseur d'accès. Nous n'achetons toutefois que de l'espace disque et de la bande passante. L'ensemble de la maintenance et du support technique a été conservé en interne. De même, c'est Assurland qui achète les racks de serveurs. Colt réalise l'hébergement au sens physique des choses et nous fournit un pare-feu mutualisé, en plus de la solution Netasq en interne.

Quelle est votre consommation moyenne en bande passante ?
Elle oscille entre 3 et 4 Mbits/s en moyenne. Assurland n'est pas un site où les visites sont régulières, les internautes ne viennent le consulter qu'une ou deux fois l'an. Par rapport à des sites d'e-commerce, nous n'avons pas non plus une saisonnalité très forte. La montée en charge est donc progressive et se gère plus facilement, sauf dans des cas particuliers engendrant beaucoup d'événementiel autour de l'automobile ou de l'assurance automobile.

Avez-vous construit une infrastructure redondante ?
Nous nous appuyons sur des répartiteurs de charge F5, dont deux fonctionnent en fail-over. Ces boîtiers adressent une douzaine de serveurs répartis entre serveurs Web et serveurs de services. Sachant que notre architecture s'appuie sur des services Web, cela nous donne une très grande souplesse car il est possible de basculer d'un serveur sur l'autre quoi qu'il arrive, ou presque. Derrière, les bases de données interrogées sont organisées en grappe.

Pourquoi avoir opté pour une architecture trois tiers ?
C'était une architecture relativement moderne à l'époque de la naissance du site car il s'agissait d'une plate-forme où un tiers pouvait pallier la chute d'un autre. Dans ce modèle, tous les tiers sont ouverts. Notre back office est ainsi lié à celui des assureurs afin de pouvoir réaliser en XML les cotations demandées par l'internaute à chacune de ses requêtes.

Pourquoi ne pas avoir retenu un système d'extraction journalière des données ?
Ce n'est pas vraiment possible en assurance car une offre s'affiche à des centaines de prix selon différents critères, par exemple le lieu d'habitation, le type de voiture… Ce qui aurait été possible, en revanche, aurait été de rapatrier des formules mais les assureurs ne le souhaitent pas pour des questions de confidentialité. Dès lors, le XML s'avère très pratique pour converser avec l'informatique des assurances, souvent un serveur d'application placé devant un mainframe.

Pouvez-vous optimiser tout de même l'affichage de vos données ?
Oui et non. Il est impossible de charger à l'avance le résultat de requêtes types car elles sont trop discordantes. En revanche, nous hébergeons pas mal de choses sur Akamai. Un certain nombre d'éléments dynamiques sont aussi hébergés par nos frontaux Web.

L'assurance est un métier à base de questionnaires. Pour des questions de facilité de maintenance et de réduction de la taille des données, nous avons opté pour des questionnaires prédéfinis qu'on assemble à partir de questions stockées dans des bases de données. La réponse à la question suivante correspond forcément à un cheminement donné. Du coup, nous pouvons bâtir à partir de nos questionnaires un modèle dynamique.

Là où cela devient compliqué, c'est que nous sommes obligés de faire des contrôles de cohérence, par exemple entre la date de naissance et la date d'obtention du permis de l'internaute.

Sur quelles technologies avez-vous construit le site ? Sont-elles toujours d'actualité ?
Nous utilisons actuellement l'environnement .Net. Cependant, Assurland a été créé à l'origine avec un mélange d'ASP et de C++. Lors du passage à un système plus moderne, le choix de .Net s'est fait naturellement.

Pourquoi .Net et pas Java ?
Assurland n'est pas un logiciel mais un produit Web. La portabilité de Java n'était donc pas un enjeu et le prix modeste des licences Microsoft en faisait un compromis assez attractif, par opposition à des serveurs d'applications.

Et pour le reste des technologies ?
Ce sont des solutions Microsoft : SQL Server pour la base de données et IIS comme serveur Web. Mon sentiment est qu'il y a 5 ans, la plate-forme LAMP était peut être un peu moins développée et robuste qu'aujourd'hui. Question prix et compétences, il était plus difficile de trouver des collaborateurs formés à Java. Aujourd'hui, nous sommes très satisfait du choix Microsoft.

Faites-vous appel à de la prestation de services ?
Non, tout est réalisé en interne pour deux raisons. D'une part, parce que notre métier est sujet à de nombreuses évolutions. Or, nous souhaitions savoir comment nos codes fonctionnent, car il faudra les reprendre par la suite.

Quand il faut faire appel à un prestataire, c'est lui qui connaît le produit et sait comment il marche. D'autre part, l'informatique est notre cœur de métier avec l'assurance. Il nous est difficile de l'externaliser sans perdre des atouts compétitifs.

Utilisez-vous des outils décisionnels pour vos données ?
Nous réalisons de l'analyse statistique à partir d'une copie de nos bases de données en temps réel. L'outil CRM, nous l'avons développé en interne car l'assurance à ses spécificités et nous désirions un outil à des prix raisonnables. Pour les aspects datamining ou Web Intelligence, nous nous appuyons sur Business Objects.

Sur quels projets travaillez-vous pour les prochains mois ?
Les principaux développements portent sur de nouveaux comparatifs d'assurance appliqués à d'autres domaines. Dans des délais non encore établis, le site devra migrer vers de nouvelles versions des logiciels Microsoft. Actuellement, nous sommes par exemple sur SQL 2000. Il faudra certainement migrer à terme, mais il n'y a pas d'urgence.
 
LAISSEZ UN COMMENTAIRE
 
0 RÉACTION
Pas encore de commentaire, soyez le premier.