Lorsqu'en 2001, le lunetier français Alain Mikli a décidé de relier ses six intranets dans le cadre d'une refonte de son système d'information, la société, qui compte aujourd'hui 250 collaborateurs, a dû repenser son infrastructure réseau. Pour assurer la connexion sécurisée des sites situés en Europe, aux Etats-Unis et en Asie, la direction a choisi de déployer un réseau VPN IP (Virtual Private Network), et retenu l'opérateur néerlandais KPNQuest. Le responsable du projet revient avec nous sur les raisons de ce choix.

"Jusqu'à l'année dernière, nos différents sites (en France, Belgique, Italie, Norvège, à New-York, Tokyo et Hong-Kong) étaient indépendants, chacun possédant une connexion locale avec son propre serveur de messagerie et de site Web", explique Nicolas Sibon, directeur technique d'Alain Mikli. En 2001, la direction générale du groupe décide d'installer un progiciel de gestion intégré central (Adonix X3) pour unifier les systèmes de facturation de ses différentes filiales et permettre au siège social, situé dans le 13e arrondissement de Paris, d'accéder à l'ensemble des sites internationaux.

Un cahier des charges exigeant
Pour garantir une ligne de communication sécurisée transcontinentale avec un débit minimum garanti, plusieurs options s'offraient en théorie à la direction technique, parmi lesquelles l'ADSL (connexion asymétrique haut-débit par modem-câble) ou une liaison WAN (Wide Area Network) de type Frame Relay. La première option n'a pas été retenue pourtant, puisqu'à l'époque aucun opérateur n'était capable, rappelle Nicolas Sibon, d'offrir une connexion ADSL en propre sur les trois continents. Quant au frame relay, le rapport qualité-prix de la proposition adressée par un opérateur français à Alain Mikli n'a pas convaincu. " Nous avions besoin d'un débit minimum garanti de 64 Kbit/s; or, en frame relay, en cas de dépassement - difficile à maîtriser pour nous -, nous étions surfacturés de façon trop importante", déclare le responsable du projet.

C'est donc finalement vers la technologie VPN IP que s'est tourné le designer optique, après avoir établi un cahier des charges assez contraignant. "La première condition à respecter était d'offrir un service uniforme sur les trois continents et des équipements de routage homogènes, pour simplifier le dépannage en cas de problème". Le dimensionnement du réseau a ensuite été pensé en fonction du nombre d'utilisateurs : "Nous sommes partis d'une hypothèse haute de 32 Kbit/s par utilisateur; ainsi avons-nous choisi une liaison de 512 Kbit/s entre New-York et Paris pour nos 10 collaborateurs américains. Le temps de latence en revanche était moins important au regard de Nicolas Sibon qui explique pourquoi. " En fixant une barre à 50 millisecondes, nous étions déjà à 50% en dessous de notre temps habituel, ce qui nous semblait satisfaisant; d'ailleurs avec un ping de l'ordre de 18 à 23 ms actuellement, nous sommes actuellement au-delà de nos espérances".

Des impératifs de sécurité et QoS relatifs
Restaient les problématiques - souvent considérées comme cruciales - de la sécurisation du réseau et de la gestion de la qualité de service. Là encore, Nicolas Sibon relativise les choses. "Nous avons adopté les mesures de sécurité que notre activité requiert : le protocole IPSec (le protocole d'encryptage des données le plus courant sur VPN IP) nous suffit donc, sans avoir à passer par des options, que propose d'ailleurs KPNQuest, de DES ou triple DES (une clef d'encryptage à 168 bits)". Quant à la gestion de la qualité de service (QoS) sur le réseau, là encore notre interlocuteur estime qu'il s'agit d'arbitrer au mieux le ratio entre la valeur d'usage d'une technologie et son coût. "De toute façon", à l'époque, MPLS (Multi Protocol Label Switching, un protocole qui gère notamment les aspects de QoS) n'était pas encore implémenté par la plupart des opérateurs, rappelle-t-il. Qui plus est, cet aspect n'est pas essentiel pour Alain Mikli, ajoute Nicolas Sibon. "La QoS permet d'attribuer un certain nombre de ports à telle ou telle application et à gérer les priorités de certains flux applicatifs et les trames IP qui les portent. Or, chez nous, la plupart des connexions qui sont faites entre les sites distants et le siège social sont d'ordre commercial : il n'y a a donc pas réellement de priorité à attribuer à tel ou tel."

Un calendrier serré bien maîtrisé
Après avoir signé avec KPNQuest en janvier 2001, le lunetier a donc commencé à mettre en chantier les déploiements parallèles de l'ERP d'Adonix et le réseau VPN IP dès mars, le second se faisant en moyenne à un mois d'intervalle avec l'installation du progiciel. "Nous avons commencé par équiper la France en mars 2001, puis ont suivi dans l'ordre entre août et décembre : la Norvège, l'Italie, la Belgique, et New-York enfin, où nous finissons actuellement la mise en exploitation de notre ERP", déclare le responsable du projet. Les prochaines échéances consisteront à alléger l'ERP côté poste client afin d'accélérer le transfert des fichiers lors d'une nouvelle implémentation globale prévue avant la fin du premier semestre. Le déploiement en Asie est également en vue pour les prochains mois, et les connexions VPN IP à Tokyo et Hong-Kong devraient être finalisées avant la fin 2002.

Si le coût total de l'opération reste pour le moment difficile à chiffrer, l'enveloppe de départ est en tout cas relativement modeste, par rapport à l'ampleur du projet. "Nous disposions d'environ 45 700 euros (300 000 francs), qui nous ont servi à couvrir les frais liés à l'installation des liaisons spécialisées dans chaque pays, et à assurer les connexions entre chaque point de présence (POP) de KPNQuest et nos sites." A cela, reste à ajouter, chaque mois, le coût de l'abonnement mensuel perçu par l'opérateur néerlandais.