Difficultés rencontrées

Même si au cours de la lecture de ce mémoire on a pu distinguer les étapes plus ou moins sensibles, il est quand même nécessaire de relever certains points qui ont posé des problèmes d’intégration, dans le cadre de cette réalisation.

Téléchargement automatique des données : la mise en place d’une routine de

téléchargement des données depuis le site de Yahoo Finance, fut un réel défi. En effet, il a fallu analyser le site Internet « dans les moindres recoins », pour trouver une

astuce d’implémentation d’une routine de rapatriement des données historiques. Pour

cela, une recherche approfondie sur le fonctionnement des requêtes URL du site de Yahoo a été menée, afin de pouvoir reconstruire un système d’interrogation similaire, au sein de l’outil de composition de portefeuilles. Ainsi, cet outil est capable d’interroger la base de données Yahoo et de télécharger les résultats dans des fichiers de données « .csv ». Ensuite, la fonctionnalité de mise à jour des indices boursiers a

nécessité la mise en œuvre d’un processus de décomposition structurelle des pages

web, provenant principalement de Yahoo Finance et parfois d’autres sites Internet30

, de manière à repérer les tableaux de données contenant la structuration des indices

30

boursiers. Ces fonctionnalités sont celles qui ont nécessité la plus grande quantité de travail.

Calcul de la matrice des covariances-variances : la principale difficulté, lors du calcul de la matrice des covariances-variances, est la comparaison des historiques

entre deux titres. Effectivement, comme l’outil autorise la manipulation de titres

provenant de divers marchés, il se trouve que les jours ouvrés de cotations historiques ne sont pas toujours les mêmes. De plus, la longueur des historiques fournis par la base de données n’est pas toujours identique, entre les différents titres. Par exemple, le site de Yahoo Finance rend disponible un historique de 35 années pour le Dow Jones et seulement quelques dizaines de mois, pour certains titres étrangers. Ainsi, intervient le problème du calcul de la covariance depuis les historiques de deux titres qui n’ont pas la même profondeur d’historique. Ce problème est d’autant plus important

quand on calcule cette matrice pour plus de deux titres, puisqu’on obtient n

profondeurs d’historiques et de nombreuses différences dans les jours de cotations.

Pour répondre à cette problématique, les solutions suivantes ont été intégrées. Tout d’abord, lorsque le programme constate des divergences en termes de journées de cotations, il élimine ces dates. Ceci n’engendre pas de réel problème, puisqu’en

principe, sur une année d’historique, cela engendre seulement la suppression de

quelques dates, de l’ordre de trois ou quatre par année. Quant à la solution adoptée

pour le problème de profondeur des historiques, le programme effectue une vérification et s’il détecte ce genre de problème, il informe l’utilisateur de la situation en lui préconisant de modifier les dates d’historiques ou de supprimer le titre de la simulation en cours. Une remarque importante concerne les divergences de cotations entre les

titres, lorsqu’on en sélectionne trois ou plus, il arrive que la covariance ne soit pas

calculée sur le même nombre exact de jours, entre chaque paire de titres. Par exemple, si l’on a deux titres américains qui ont un historique de 252 jours et un titre suisse cotant sur 250 jours, alors le calcul de la covariance entre les deux titres américains s’effectuera sur les 252 jours et celui entre le titre suisse et chaque titre américain se fera sur 250 jours, suite à la suppression des jours fériés suisses dans l’historique américain.

Problème d’interopérabilité VBA-VB.Net au niveau du solveur : suite à l’évolution

.Net, Microsoft a rendu disponible l’ensemble de la librairie objets VBA des outils

Microsoft Office aux programmeurs .Net. Cela a donc nécessité un gros travail d’adaptation des librairies par les équipes de développeurs de Microsoft. Toutefois, la fonction « Solveur » d’Excel, qui est considérée comme une des fonctionnalités importantes de ce logiciel, fut développée par une société indépendante.

Malheureusement, cet outil d’optimisation n’a pas subi la même adaptation que la suite Microsoft, ce qui le rend indisponible aux développeurs .Net. Cette constatation a donc

compliqué la phase de développement de l’outil. Pour contourner cet obstacle, une

macro VBA d’interaction avec le solveur fut codée. De manière à interagir avec cette macro, une routine de contrôle et d’exécution a été élaborée en VB.Net, afin de transmettre les paramètres nécessaires à la macro et d’obtenir les résultats de l’optimisation en retour dans VB.Net.

Génération d’erreurs avec les formules Excel : une constatation étrange concernant l’utilisation des formules d’Excel, depuis VB.Net, fut relevée. Lorsque les calculs étaient effectués sur une très grande quantité de données et en utilisant certaines formules préprogrammées d’Excel, par exemple celle du calcul de l’écart-type, les résultats obtenus renvoyaient un message d’erreur. Puisqu’aucune solution n’a été trouvée, il a été décidé de reprogrammer ces fonctionnalités en VB.Net et de les exécuter en mémoire, au lieu d’écrire les formules dans les feuilles de calculs d’Excel.

Dessin des graphiques : le dessin des graphiques est sans doute la seconde étape la plus consommatrice de temps. De nombreux problèmes techniques ont été rencontrés, à cause de certaines inefficiences dans l’adaptation du code en VB.Net. En effet, certaines structures de codage essentielles au langage VB.Net dans le cadre de la manipulation des objets ne fonctionnaient pas toujours correctement, car leur

adaptation nécessitait certaines ruses qui n’étaient pas très commodes. De plus, au

niveau de la présentation des graphiques, certaines limitations liées à l’outil Excel ont

été constatées. Malgré l’existence d’une fonctionnalité de positionnement dans

l’espace des séries de points sur les graphiques, Excel place automatiquement en arrière-plan les séries liées par une courbe. Le problème étant que lorsqu’on simule une grande quantité de points avec la méthode de Monte-Carlo, ils viennent

automatiquement masquer la représentation de la frontière efficiente, puisqu’il s’agit

d’une droite ou d’une courbe selon la situation. Pour contourner cette contrainte, la frontière efficiente est représentée sous la forme d’une série de points, au lieu d’une droite.

Complexité et quantité de code : la dernière difficulté majeure fut l’augmentation du

code, en fonction de l’évolution du programme. Naturellement, au début il est très facile de se repérer au sein du code et d’apporter des modifications. Mais lorsque vous dépassez les 3000 lignes, chaque modification devient un vrai casse-tête, puisqu’elle

manipulations. Ces observations sont la cause d’un ralentissement important en termes de production, car il est nécessaire de bien réfléchir à la façon la plus simple d’adapter les transformations, survenues au cours du développement.

Pour terminer, de nombreux autres petits obstacles plus ou moins passagers sont apparus, au fil de la mise en place de l’outil. Pour arriver à la version actuelle du

programme, ils ont pour la majorité été contournés ou résolus via l’utilisation de

subterfuges. Leurs principaux impacts furent de mener à une dépense supplémentaire en temps et à un stress important, liés au respect des délais impartis.