Windows NT Terminal Server en action

L’entreprise, une société d’ingénierie des structures, souhaitait étudier et déployer
une solution WAN pour relier deux agences satellites à  son siège. Chacune des
deux agences distantes compte une dizaine d’utilisateurs, alors que le siège en
possède une trentaine. La solution déployée se composait de liaisons privées à 
relais de trame à  128 Kbps entre les agences distantes et le siège et d’une liaison
à  384 Kbps du siège à  Internet.

Cette solution permet aux agences d’accéder aux ressources du site central, notamment
un système de messagerie Exchange et des partages de fichiers et d’impression.
Les agences distantes peuvent, en outre, utiliser le serveur proxy du siège pour
accéder à  Internet avec un dispositif d’adressage IP privé, cohérent avec le système
central. Grâce à  ce point de contact unique avec Internet, cette configuration
permet aux administrateurs d’exercer un contrôle centralisé de l’accès à  Internet
et réduit la complexité de la configuration. La Figure 1 montre l’architecture
du réseau de la société.

Une fois les liaisons par relais de trame mises en place, j’ai ajouté des BDC
à  chacune des agences pour assurer l’authentification locale et la centralisation
des services de fichiers et d’impression. Après m’être assuré que tout fonctionnait
comme prévu dans le nouvel environnement WAN, je pensais que l’entreprise n’avait
plus besoin de mes services.

Mais environ une semaine plus tard, j’ai reçu un appel téléphonique de mon client
qui changeait tout. Un détail important avait été omis lors d’une réunion d’étude
préparatoire. Les utilisateurs se trouvant dans les agences avaient besoin d’accéder
à  une application de comptabilité du siège utilisant une base de données Access.
Après mon départ, le personnel du service informatique de l’entreprise avait configuré
les utilisateurs des agences pour leur permettre d’accéder à  cette application.

Or ces derniers avaient rencontré des problèmes de fonctionnement importants en
essayant d’utiliser l’application et les liaisons WAN dans cette configuration
et le client voulait savoir comment résoudre le problème. J’expliquai les problèmes
inhérents à  l’exécution d’une base de données relationnelle partagée sur une liaison
WAN à  faible bande passante (avec en moyenne au moins cinq à  six utilisateurs
simultanés à  chaque point). Après avoir évalué la situation et pris en compte
les nouvelles informations, j’ai donc commencé à  mettre sur pied une solution.

Ce problème pouvait être adressé de deux manières : assumer le trafic ou le réduire.
L’une consistait à  augmenter les vitesses des liaisons relais de trame pour prendre
en charge le trafic supplémentaire. L’autre, celle de mon client, consistait à 
mettre à  niveau le système de comptabilité en passant à  une nouvelle version basée
sur SQL Server (ce que l’entreprise envisageait de toute façon). J’ai également
discuté avec l’entreprise de la possibilité de combiner ces deux idées.

Les deux solutions présentaient en effet de gros inconvénients respectifs. L’augmentation
de la bande passante des liaisons par relais de trame pour atteindre le niveau
nécessaire à  l’exécution de l’application signifiait des coûts initiaux élevés,
plus l’éventualité plus que probable de doubler les factures mensuelles de transmission
des données. Les dirigeants de l’entreprise ne verraient certainement pas cette
perspective d’un bon oeil.

Certes migrer vers une application basée sur SQL Server permettait d’améliorer
l’efficacité et la fiabilité en passant à  une base de données de type client-serveur,
mais signifiait aussi le risque de dépenses imprévues. Pire encore, l’éditeur
du système de comptabilité ne jugeait pas l’application basée sur SQL Server beaucoup
plus rapide ni capable de résoudre les problèmes de performances.