Dans les grands établissements financiers, la dette technique est classiquement élevée. On entend par « dette technique » les coûts associés à un système d'information non-optimisé issu des multiples couches historiques. Dans le cas de Natixis, l'histoire technique est liée à celle de l'entreprise, faite de nombreuses fusions et réorganisations. Travailler sur la qualité globale du système d'information a cependant permis de réduire la dette technique.
« Notre système d'information est un assemblage de multiples applications issues de technologies et de cultures de développement différentes » témoigne Bernard de Nailly, responsable du service architectures de développement" à la direction systèmes d'information achats logistique de Natixis. Il ajoute : « nous avions besoin de rationaliser pour baisser nos coûts, accroître la maintenabilité, la qualité de service, la pérennité et l'agilité ». Le but n'est pas réellement de baisser le coût globale de l'informatique mais bien de le maîtriser tout en réaffectant des gains sur les coûts d'exploitation en budgets de développements.

Si le socle repose avant tout sur des mainframes IBM avec du Cobol et du Cobol/Pacbase, Natixis utilise aussi, notamment, du Java/J2EE pour les services bancaires et du .Net pour les divisions se consacrant aux financements structurés. Par dessus tout cela, le décisionnel se répand au travers de plusieurs outils différents comme BO et Cognos.

La complexité en ligne de mire

A cette variété technologique s'ajoute une complexité croissante des systèmes. Bernard de Nailly souligne : « une application n'est plus un programme mainframe plus ou moins isolé mais un assemblage complexe de logiciels aux technologies différentes. » Pour limiter la complexité, Natixis a pris le parti, autant que possible, de faire reposer son système d'information sur un maximum de progiciels, lorsqu'il n'y a pas de valeur ajoutée spécifique lié à un savoir-faire propre à l'entreprise. A l'inverse, Natixis n'hésite pas à réaliser des développements particuliers quand l'entreprise dispose d'une telle valeur ajoutée qui implique une évolution des processus métier par rapport aux possibilités offertes par les progiciels.
A cette répartition entre le développement et les progiciels s'ajoute la problématique de l'off-shore et, d'une manière générale, de l'externalisation. « Nous avons besoin de suivre ce qui est externalisé » insiste Bernard de Nailly. Décomplexifier le système d'information tout en suivant la qualité de la production de code implique de mesurer la qualité globale applicative. C'est là qu'intervient la méthode Sqale.

Une politique de petits pas

Il n'existe en effet pas de norme reconnue pour la qualimétrie logicielle. Sqale est donc une méthode visant à optimiser la qualité du système d'information. Pour la mettre en oeuvre à moindre coût, Natixis s'est appuyé sur le logiciel libre d'analyse de code Sonar. « Même si nous utilisons Cast lorsque c'est utile, le coût de ce produit n'était pas compatible avec une généralisation de la méthode dans l'entreprise alors que Sonar nous suffit en général » explique Bernard de Nailly. Sonar possède d'ailleurs un module Sqale.

La mise en oeuvre de cette démarche s'est faite à l'instigation du cabinet de conseil Inspearit à partir d'il y a un peu plus d'un an. Pour Bernard de Nailly, « les équipes étaient bien adaptées à l'état d'esprit de la maison, avec des ambitions limitées au départ, une montée progressive en puissance et un accompagnement approprié ». En effet, Natixis a choisi de déployer la méthode Sqale petit à petit. Cela permet de valider les bénéfices de la démarche sur un périmètre réduit avant d'étendre ce périmètre. « Même si le projet a supposé un soutien fort de la DSI, une adoption pérenne de ce type de démarche suppose que les collaborateurs se l'approprient et donc que la méthode soit acceptée volontairement et non pas imposée » martèle Bernard de Nailly. Même si l'objectif à terme est de généraliser son emploi, Sqale n'est à ce jour déployé que sur les deux tiers du système d'information, un déploiement sur 70 à 80 % étant attendu en 2013.

Le coût de Sqale se chiffre à hauteur de 60 à 70 jours.homme. Le problème de la qualimétrie est de mesurer le retour sur investissement de ce coût. « Il n'est pas aisé de mesurer des gains directs mais on gagne en maintenabilité, évolutivité, agilité, qualité de service, calcul des coûts plus aisé... » soutient Bernard de Nailly.