Un traider serait donc la cause de 5 Milliards de perte pour la SG…
Pour arriver à ce niveau de perte, il aurait spéculer sur 50 Milliards d’euros !
Au début, je ne pensais pas que c’était possible, je penchais donc pour une maneuvre pour charger un bouc émissaire de tous les mauvais placements… Puis mes différentes lectures (ici par exemple) m’ont fait douté : oui, il semblerait que cela soit possible !
Pourtant, la SG dépense des sommes colossales pour son système d’information, dont pas mal de millions d’euros pour la sécurité et le contrôle.
Que peut on en conclure ?
A mon sens, ce qui est marquant, c’est la non maîtrise de ces systèmes d’information.
Pour arriver à un tel résultat, il faut que le système ne soit pas compris par les personnes qui l’analysent.
Et le prix que l’on paye une armée de consultants n’est pas un outil de mesure de qualité…
D’où mon image : la pyramide est inversée, le système est gros et lourd, mais quelques grains de sable peuvent tout faire tomber.
Update de 20h35
En relisant mon billet, je me suis dit que j’étais pas assez explicite.
Petit complément donc.
Un système d’information, c’est du code qui s’exécute. Ce n’est pas une abstraction.
Pour analyser un système, il faut analyser le code. C’est donc pas un travaille ou on manipule des abstractions…
J’ai travaillé dans les banques dans ma jeunesse. Les documents d’analyses ne correspondent pas à ce que font les programmes… Quand il y a des documents d’analyse ! Je me souviens d’une très grosse banque, qui avait un programme très important, au coeur du système. Le programme avait été écrit avec PAC, un générateur de programmes Cobol. Quand je suis arrivé, le programme PAC était perdu, il n’y avait aucun document d’analyse… Donc, la seule façon de comprendre les règles métiers, c’était d’analyser le code généré par PAC… C’est une illustration de la pyramide inversée. Dans un tel contexte, tout peut arriver !
Tiens, pour une fois on est d’accord : regarde ce que j’ai écris sur mon (autre) blog :
« Société Général : il faut virer le Directeur Informatique »
@Olivier> Mais oui on est d’accord ! Enfin presque 😉
PAC ça doit etre pacbase (souvenirs souvenirs).
Sinon je ne suis pas d’accord : les informaticiens font ce que les fonctionnels leur demandent. Le service informatique n’est pas décideur, le SI n’est qu’un outil au service du métier 🙂 C’est donc les gens du métier les fautifs.
c’est exactement ca, un peu comme l’avion qui crashe parce que le pilote ne comprend pas l’ordi…
typiquement bureaucratique : d’un coté on installe un produit très cher et complexe, de l’autre on ne tient pas compte de ses alertes et on prend pas le peine de le configurer vraiment… ^^
ce n’est pas une question d’informatique, mais de son utilisation, de formation. et finalement que le client (ici le chef du trader, les équipes de gestion…) veuille vraiment utiliser l’outil… sinon ca ne sert à rien
aucun outil informatique ne peut rien s’il n’est pas intégré à la gestion de l’équipe, de l’entreprise. (ca rejoint un peu votre post sur les étapes de prod)
eh eh mais j’aime bien l’image de la pyramide inversée, j’ai connu ca aussi…
déduire les règles clients à partir des traitements de base, et établir de beaux diagrammes uml par rétroingenering du code ! 🙂
ou le cahier des charges finalisé après le développement… plus l’entreprise est grosse, plus on a de surprises… 🙂