 |
|
| |
 |
Pierre-Antoine Durgeat
Directeur
technique
Mappy |
|
Pierre-Antoine
Durgeat
"La gestion de la charge serveur est essentielle pour nous"
Exploration du métier de responsable informatique de site Web avec le directeur technique de Mappy qui justifie les différents choix d'environnements pris par le spécialiste des cartes sur Internet.
26/07/2005 |
| |
|
|
JDN Solutions. Pouvez-vous
présenter votre groupe et vos activités ?
Pierre-Antoine Durgeat. Mappy est une filiale du
groupe PagesJaunes, elle-même filiale de France Télécom.
Mappy.com et Mappy.fr constitue la partie guide, MappyPro
propose une gamme de services géographiques à destination
des professionnels et MappyVisiocity, un inventaire photographique
des villes. Des services sont également disponibles sur
téléphones mobiles.
Comment la direction technique
s'est-elle organisée autour de ces différentes activités ?
Mappy possède une plate-forme unifiée, baptisée LBS ou
Location Base Services, et destinée à l'ensemble des fonctions
géographiques de Mappy. Nous sommes à la fois éditeur
et hébergeur de sites Web. L'équipe regroupe une vingtaine
de personnes, essentiellement des développeurs C++ et
des spécialistes en bases de données, ainsi que deux personnes
chargées de l'exploitation.
Cette
structure est héritée de l'activité de services de la
prévention routière itinéraire qu'effectuait iTi sur minitel
jusqu'en 2000. A partir de l'an 2000, Mappy à ouvert un
site Internet sous cette marque, appuyé par une forte
communication auprès des médias.
Sur quelles technologies s'appuyaient
alors le site ?
Essentiellement sur une base de données Oracle et un serveur
d'application Hahtsite. La plate-forme initiale en 2000
était hébergée sous un système d'exploitation Sun majoritairement,
via le prestataire Exodus basé en Angleterre.
Y a t'il eu des changements
depuis ?
Oui, nous avons repris l'architecture pour la migrer sous
Windows avec la base de données SQL Server, ceci afin
de réduire les coûts de montée en charge d'un ensemble
Oracle/Sun. Aujourd'hui, nous exploitons en plus un serveur
d'applications XML développé en interne. Ce dernier choix
fait suite à plusieurs soucis de performances que nous
avions rencontrés en 2002 sur le site.
|
|
 Nous
sommes capables de monter d'un facteur 10
la charge" |
|
Pour illustrer la nouvelle architecture, nous avons organisé
la plate-forme en une ferme de serveurs identiques et
indépendants. La répartition de charge s'effectue par
des serveurs Linux en frontal, la compression de flux
par les serveurs d'applications. Les recherches des internautes
et donc les pages générées sont souvent uniques, ce qui
ne se prête pas bien à l'optimisation de requêtes. Le
moteur se base donc sur des algorithmes capables de minimiser
les délais. Il occupe près de la moitié de l'équipe d'entretien
de la plate-forme.
Pourquoi avez-vous choisi ces
solutions à l'époque ?
Nous disposions alors d'un délai de six mois pour
effectuer la migration, or l'équipe, soutenue par Microsoft,
comprenait déjà des compétences sur SQL Server et Windows.
La transition s'est effectuée en bonne intelligence avec
Microsoft, et aujourd'hui c'est un choix que nous ne regrettons
pas. Avec cette nouvelle architecture technique, nous
avons quasiment divisé par trois les coûts d'infrastructure,
et elle tient encore la route aujourd'hui.
Comptez-vous aussi remplacer
cette plate-forme à terme ?
Nous toucherons forcément la limite à un moment donné,
mais actuellement nous sommes capables de monter d'un
facteur 10 la charge. Aujourd'hui, Mappy utilise 53 serveurs
Intel au quotidien et nous pourrions gérer sans problème
jusqu'à 100 à 150 serveurs.
Le site s'avère surtout gourmand en puissance de calcul,
en raison des algorithmes, moins en bande passante. La
gestion de la charge serveur est donc essentielle pour
nous et explique sans doute les performances en environnement
Microsoft, un environnement qui selon moi s'adapte particulièrement
aux besoins en matière de développements.
|
|
Notre
serveur d'applications XML est un élément
important de la souplesse de Mappy" |
|
Comment fonctionne l'hébergement
de vos serveurs ?
Avant, nous étions chez Exodus en Angleterre. En 2002,
nous nous sommes déplacés chez Tiscali puis chez France
Télécom. L'opérateur nous loue une partie de ses locaux
et nous administrons notre plate-forme à distance. Comme
l'équipe se trouve à seulement 5 kilomètres du site, elle
peut s'y déplacer très rapidement si besoin et une visite
régulière est effectuée toutes les deux semaines environ.
En termes de bande passante, nous consommons environ 110
Mbits.
Pourquoi avoir développé votre propre serveur d'applications ?
Après étude, IIS ne pouvait pas être conservé pour des
questions de performance, de plus le couple Apache/Windows
n'était pas très performant à l'époque. Nous nous sommes
alors posé la question de l'optimisation des performances
et ce qui a commencé par des petits développements, a
fini par un développement complet. Ce qui a été fait ressemble
beaucoup à Cocoon par exemple, il s'agit d'un élément
important de la souplesse du site Mappy.
Il nous apporte plusieurs avantages : il est construit
pour offrir des services hébergés sur une multitude de
machines, il peut gérer la perte éventuelle
d'une machine et il sépare la couche application de la
couche présentation des données. Dans la pratique, cette
séparation nous permet de fournir très facilement nos
services pour des tiers comme nous le faisons avec les
Aéroport de Paris, Ikea, Flunch ou Orange WiFi.
Par dessus le serveur d'application XML, la couche de
présentation utilise XSL avec une énorme partie du site
en Flash.
|
|
Nous
sommes constamment à la recherche de
nouveaux talents" |
|
Quels seront vos prochains
projets à court ou moyen terme ?
Aujourd'hui, un des principaux projets pour maintenir
la fiabilité de la plate-forme consiste à établir un site
secondaire. Monter au delà de la disponibilité actuelle
du site principal sera quasiment impossible sans un deuxième
site. De plus, il y a toujours un risque réel d'héberger
son site sur une seule plate-forme physique. Mettre en
place un site secondaire nous permettrait donc d'être
plus serein pour l'avenir.
Quelle est votre vision de
l'organisation d'une directeur technique
Côté management, nous essayons de séparer la partie plate-forme
de la partie site Internet. Nous établissons une feuille
de route sur la plate-forme avec une visibilité à un an
qui est ensuite relayée aux équipes marketing. Ils construisent
alors le site sur cette base. Le témoin est ainsi transmis
aux équipes marketing afin d'établir la relation avec
le public.
Les développeurs sont des gens très créatifs, il faut
leur donner de l'espace pour étendre cette créativité.
Cela nécessite de l'autonomie mais aussi la présence d'un
architecte afin de garantir la cohérence de l'ensemble.
Cet architecte occupe plutôt une fonction transverse que
hiérarchique.
et de votre métier ?
J'ai plusieurs rôles, dont celui de maintenir un management
de proximité au quotidien. Une part importante de mon
temps est aussi consacrée au comité de direction. J'y
joue un rôle assez important sur le coté prospectif de
nos services. Il faut assurer une veille permanente, en
rencontrant des interlocuteurs internes ou externes, pour
ne pas se laisser surprendre et saisir des opportunités
dès qu'elles se présentent. Par ailleurs, nous
sommes constamment à la recherche de nouveaux talents
pour enrichir l'équipe.
| La
DT de Mappy.fr |
| La
direction technique |
|
Effectif
|
20 personnes
|
|
Les solutions
technologiques |
|
Serveur
Web
|
Interne
|
|
Langage
de développement
|
C++,
Flash
|
|
Bases
de données
|
SQL server
|
|
Systèmes
d'exploitation
|
Windows
|
|
Moteur
de recherche
|
Interne
|
|
| |
Propos recueillis par Yves DROTHIER, JDN Solutions |
|
|
PARCOURS
|
|
|
| |
Pierre-Antoine Durgeat, est directeur technique
en charge des développements informatiques
pour le moteur de recherche géographique
mappy.com.
Depuis 2002 : Directeur technique Mappy SA,
réorganisation et refonte de l'activité technique
et du site www.mappy.com
En 2002 : Fusion avec Mappy (ex iTi), rattachement
au groupe PagesJaunes
2000-2002 : Directeur technique de S.N.V
En 2000 : Rachat par France Telecom de S.N.V
(Société de Numérisation de Ville)
1997-2000 : Fondateur associé, en charge
conception de la chaîne de production VisioCity,
l'inventaire photographique urbain.
|
|
|
|
|
|
|
Dossier 
