Blog - Economie du Risque

La crise dite des subprime que nous vivons depuis Août 2007 est la conjonction de trois crises qu’il convient de dissocier :

1. Une crise économique
2. Une crise technique
3. Une crise psychologique

La crise économique correspond au dégonflement de la bulle immobilière aux US qui a commencé mi-2006. Cette crise se matérialise par une augmentation des défauts de paiements sur les prêts immobiliers, des saisies immobilières et une baisse des prix de l’immobilier. Elle s'est ensuite étendue progressivement à (presque) tous les pays de l'OCDE courant 2007, France incluse (voir notre article Dix ans de-Pensée Unique Immobilière et Après).

Les crises technique et psychologique sont purement financières.

La crise technique a deux facettes :

1. Crise du mark-to-market qui oblige les banques à valoriser certains actifs en valeur de marché dans leurs bilans
2. Crise de la titrisation liée à la complexité et l’opacité des instruments financiers de type produits structurés de crédits

Que se passe-t-il si il n’y a plus de marchés ?

C’est toute la question et personne ne semble s’être préoccupé de cette hypothèse lors du développement de la titrisation et de l'application du principe de valorisation en valeur de marché.

De nombreux auteurs ont écrit sur les méthodologies et les outils de gestion du risque opérationnel^[1]. Une revue de ces contributions sort du cadre de cet article, nous nous bornerons donc à rappeler certains principes généraux (souvent de bon sens). La mise en place d’un management du risque opérationnel d’un projet informatique suppose une réflexion autour de trois thèmes : l’organisation, la méthodologie et les ressources humaines.

Au niveau organisationnel, la gestion des risques est réalisée en fonction de la nature des risques sous-jacents (cf. tableau ci-dessus).

Le mark-to-market (valorisation en juste valeur) est une méthode de valorisation d’actifs qui s’est développée dans les activités de trading pour compte propre des banques au cours des années 80. Cette méthode consiste dans le cas le plus simple à valoriser un actif financier donné par son prix de marché en date de valorisation. La logique consistant à dire qu’un actif financier doit être valorisé en valeur de liquidation, c’est-à-dire par la contrepartie en devises que l’on obtiendrait si l’on vendait cet actif sur le marché.

Cette approche a ensuite été étendue (mark-to-model) pour valoriser des instruments peu ou pas liquides selon plusieurs approches :

1. Valorisation par arbitrage (méthode du synthétique)
2. Valorisation par arbitrage théorique ou actualisation (pricing)
3. Valorisation par modélisation économétrique (pricing++)

Tous les instruments financiers détenus par les banques dans leur portefeuille de trading (compte propre) sont valorisés selon une de ces 3+1 méthodes qui toutes relèvent de la même logique.

Utiliser le prix de marché ou un proxy de prix de marché

La refonte du système de gestion financière au sein d’une institution financière ou d’une entreprise (gestion de trésorerie) est souvent présentée comme un facteur de réduction des risques et des coûts opérationnels. Pourtant, de nombreux projets échouent du fait de la complexité technique, fonctionnelle et opérationnelle de tels projets qui, de plus, impliquent bien souvent un re-engineering des process et des méthodes.

Ainsi, P. Jorion^[1] rapporte que les projets d’implémentation de solutions intégrées front-to-back chez CSFB comme chez Salomon Brothers ont subi des retards et des dépassements de budget pour un coût total supérieur à $100M chacun. Et il ne s’agit pas de cas isolés. Philips^[2] a montré qu’environ 80% des projets informatiques échouent du fait de dépassements de délais et de budgets significatifs avec comme « scénario catastrophe » l’échec total du projet et son abandon pur et simple.

L'occasion de faire le point sur les problèmes et leurs causes.

Les projets de refonte de systèmes informatiques de gestion financière ont en général des enjeux et des périmètres d’application très différents selon qu’il s’agit de banques commerciales, de banques centrales, de gestions pour compte de tiers, d’assureurs ou d’entreprises industrielles.

Quelque soient leurs ampleurs, cinq étapes sont (au maximum) requises pour l’accomplissement de tels projets :

1. Sélection
2. Spécification
3. Développement
4. Implémentation
5. Production

Les étapes 2 et 3 ne concernent que les projets d’une certaine taille pour lesquels des fonctionnalités manquantes sur la (les) version(s) standard(s) du (des) logiciel(s) sélectionnée(s) nécessitent des développements complémentaires.