L’effet ciseaux de la qualité logicielle

Faire l’impasse sur la qualité des applications n’est plus une option pour les DSI, sujet auquel les directions générales sont de plus en plus sensibles. Les témoignages de Allianz, BNP Paribas, du Crédit agricole, du PMU et de la SNCF recueillis lors d’une table ronde organisée par Cast Software.

Les DSI sont pris dans un effet ciseaux : d’un côté, les prix des applications et des services fournis aux directions métiers doivent diminuer et, d’un autre côté, la qualité doit augmenter. À un moment donné, les courbes de la baisse des prix et de la croissance de la qualité se croisent et, de fait, cela pose un problème délicat aux DSI.

« Nous sommes en permanence challengés sur les prix et la qualité, qui ne doit pas baisser », confirme Éric Grasset, directeur des prestations systèmes d’information de la SNCF-DSIT. Si la qualité passe avant tout par une meilleure adaptation aux besoins métiers, elle passe également par la qualité des applications produites.

« C’est un objectif que nous partageons avec nos sous-traitants, surtout ceux qui proposent des modèles offshore et qui ne sont donc pas sur place », ajoute Éric Grasset. Selon Didier Lambert, ex-DSI d’Essilor, « la démarche qualité est le point commun entre les trois missions d’un DSI : délivrer des services de bonne qualité, maîtriser les coûts et satisfaire les utilisateurs, de plus en plus exigeants ».

Pour Renaud Hilleret, directeur adjoint, responsable du pôle systèmes d’information de Caagis (Crédit agricole assurances), « l’impact de la non-qualité logicielle se matérialise à la fois sur les performances de l’IT (plus de charges de tests et de corrections, moins de possibilités de réutilisation, croissance du coût des évolutions, moins de fluidité dans les équipes de développement, applications plus consommatrices de ressources en production) et sur les performances des métiers (efficacité des utilisateurs, réactivité dans la mise à disposition de nouveaux produits, respect des contraintes réglementaires, image de marque…) ».

Chez Allianz France David Horvat, le DSI, explique : « La rationalisation de nos investissements a justifié que nous investissions dans la qualité des applications. Il faut en effet considérer la dimension patrimoniale du système d’information, et sa contribution à la transformation de l’entreprise. Cela coûte très cher de le faire évoluer, d’autant que le SI fonctionne de plus en plus en temps réel et critique pour une compagnie d’assurances. »

La qualité passe aussi par les sous-traitants

Au PMU, la qualité est abordée sous deux angles. D’une part, la garantie de continuité de services, dans un environnement où le temps réel est incontournable : « Lorsque l’informatique s’arrête, le PMU s’arrête », résume Christophe Leray, DOSI du PMU.

Et, pour le PMU, un jour d’arrêt peut coûter jusqu’à 25 et 35 millions d’euros et pour les périodes de pointe, les pertes peuvent atteindre un million d’euros en seulement dix minutes. D’autre part, avec la mesure de la qualité des fournisseurs et des développements. En 2006, le PMU a mis en place un système de mesure de la qualité de ses sous-traitants puis, dans un second temps, s’est intéressé à la qualité du logiciel. « Si la qualité des matériels est globalement bonne, le logiciel n’est pas fiable et sa stabilité est bien l’enjeu, car 100 % de nos incidents sont dus aux logiciels », ajoute Christophe Leray.

Pour Dominique Marichal, responsable département qualité et méthodes du groupe BNP Paribas, la qualité du code consiste à « s’assurer que l’actif sera opérationnel », c’est-à-dire que les pannes en production seront limitées et que les prestataires seront contrôlés : « Aujourd’hui, pour nos opérations de TMA et de TRA, nous ne réceptionnons pas les livrables si leur qualité n’est pas démontrée, avec des mesures factuelles. »

Une approche similaire a été adoptée à la SNCF : « Nous sommes une entreprise d’ingénieurs et, si la qualité et la sécurité sont depuis longtemps au cœur des processus métiers, la qualité du code reste une faiblesse, surtout avec des partenaires qui ont des cultures différentes et qui travaillent dans des lieux très dispersés, précise Éric Grasset. Mais désormais, le code qu’ils nous livrent doit être parfaitement maintenable et évolutif. »

« La qualité a un impact sur le risque opérationnel, soutient pour sa part Fabien Sauvage, consultant associé chez Deloitte. Les directions métiers vont s’intéresser de plus en plus à la qualité pour développer leurs activités et participer aux choix applicatifs. »

La dimension qualité est également de plus en plus considérée dans les opérations de rapprochements entre entreprises : « Nous avons vu des cas, dans le domaine de la protection sociale, où des rapprochements ne se sont pas réalisés du fait de la mauvaise qualité des applications qui aurait accru les risques », rappelle Fabien Sauvage.

Par où commencer ? « Une démarche qualité débute souvent par un peu de bricolage, par exemple à l’occasion d’une crise, d’un incident, ou d’une interrogation sur l’opportunité de conserver une application », explique David Horvat, DSI de Allianz France. Pour ce dernier, le niveau de maturité se trouve accéléré par deux phénomènes : la qualité du sourcing et les méthodes de développement agiles, qui permettent des itérations rapides.

Qualité logicielle : les avantages pour les différents interlocuteurs de la DSI
Interlocuteurs de la DSI Avantages
DG/maîtrise d’ouvrage
  • Justification (budget, arbitrage, portefeuille de projets)
  • Analyse de risque
  • Certification
  • Obligations réglementaires
  • Sensibilisation
  • Établissement des priorités
  • Factualisation
  • Identification des responsabilités
Équipes internes
  • Sensibilisation
  • Allocation de ressources
  • Suivi de la performance
  • Factualisation de la relation
  • Identification des responsabilités (fonction de « juge de paix »)
Éditeurs de logiciels
  • Audit de pérennité technique avant acquisition
  • Responsabilisation
  • Rajout d’indicateurs dans les contrats
Sous-traitants
  • Responsabilisation
  • Contractualisation (avec des engagements de niveau de qualité)
  • Suivi des engagements
  • Réversibilité
Source : Crédit agricole assurances.

Fiabiliser la mesure

« Nous avons commencé par placer la qualité comme objectif stratégique, en élaborant des indicateurs et des tableaux de bord pour le management afin d’identifier les axes d’amélioration », explique Dominique Marichal, de BNP Paribas, qui identifie trois facteurs clés de succès : l’appropriation des tableaux de bord par la direction générale, la communication permanente et des processus industrialisés et reposant sur l’emploi d’outils, simples et personnalisables (pour les projets, pour la maintenance…).

Bilan, chez BNP Paribas : 3 à 5 % d’économies sur le budget informatique. Chez Allianz, l’objectif est d’obtenir 15 % de gains sur les activités de développement. « En passant au niveau 2 de CMMi, nous avons gagné huit points, rétrocédés aux clients internes », précise David Horvat, qui estime pouvoir gagner autant en atteignant le niveau 3 de CMMi. Quelle que soit l’approche, « si la qualité logicielle concerne toujours les managers, le système de pilotage doit rester côté donneurs d’ordres, donc de la DSI, ce qui n’interdit pas aux prestataires d’utiliser les mêmes outils, bien au contraire », précise Renaud Hilleret.

Appuyer une stratégie d’amélioration de la qualité sur des indicateurs suppose que l’on puisse mesurer. « Pour mesurer, il faut un outil et une norme », insiste Didier Lambert. Ce qui n’a rien d’évident : « Établir des mesures reste compliqué, confirme Dominique Marichal, de BNP Paribas.

Si les indicateurs n’en sont pas rattachés aux perspectives stratégiques, cela ne sert à rien, et je déconseille de partir dans toutes les directions, il est préférable de se baser sur quelques indicateurs partagés par le plus grand nombre plutôt que sur plusieurs dizaines, voire centaines de chiffres. » Renaud Hilleret conseille : « Il faut axer la démarche sur le partage d’informations. Il ne s’agit pas de sanctionner, mais de mieux mesurer pour progresser. C’est plus simple à mettre en œuvre que l’on pourrait l’imaginer, et le seul risque porte sur la manière dont on l’introduit dans l’organisation et l’usage que l’on en fait. »

Pour David Horvat, « cela suppose de bien positionner les informations recueillies dans la chaîne de valeur de l’entreprise pour identifier les éléments critiques ». Sans trop se tromper car, en matière de qualité des applications, la direction générale n’est jamais loin. « Le président garde toujours gravées en tête les quelques dates clés où l’on a connu des incidents », soupire Christophe Leray, DSI du PMU. « Quant au nôtre, il déteste se retrouver au journal de 20 heures », confirme Éric Grasset…

Quatre cas d’application d’une approche qualité logicielle au Crédit agricole assurances
Cas d’application Contexte – Enjeux – Besoins Actions réalisées Résultats
Opération de
croissance externe
  • Projet d’acquisition d’une société d’assurances
  • Le système d’information est différenciateur
  • Besoin de compléter les audits fonctionnels et d’architecture par un audit de pérennité technique
  • Bilan de santé technique
  • Audit d’évolutivité
  • Présentation des résultats à la direction générale
  • Prise en compte des résultats dans la décision finale
Évaluation du patrimoine
  • Prise de poste dans un contexte sensible
  • Besoin de visibilité objective sur le niveau de risque rencontré
  • Bilan de santé des applications critiques
  • Identification objective des points d’attention
  • Visibilité sur le risque et le niveau de maturité du delivery
  • Facilitation du dialogue avec les équipes
  • Sensibilisation et responsa­bilisation aux bonnes pratiques de développement
Audit de performance
et de stabilité
  • Situation de crise sur une application critique
  • Problème de performance et de stabilité non résolu
  • Besoin de lancer un chantier de fond en complément d’une analyse dynamique
  • État des mieux de la santé globale de l’application
  • Focus sur l’axe performance / stabilité
  • Définition d’un plan de remédiation
  • Mise en place d’actions correctrices
  • Mise sous surveillance de l’application
  • Amélioration constatée des performances
Étude de pérennité
  • Application stratégique ancienne
  • Besoin d’arbitrer sur son devenir
  • Bilan de santé orienté possibilités d’évolution/maintenance/possibilités de transferts
  • Présentation des résultats aux équipes de la DSI
Source : Crédit agricole assurances.

Le risque caché de la dette technique

Le coût nécessaire pour remédier aux défauts toujours présents dans une application une fois qu’elle est opérationnelle dépasse le million de dollars pour une application métier standard, selon une étude de Cast Software. L’étude a été menée en réalisant une analyse automatisée de la qualité structurelle de 288 applications issues de 75 sociétés de secteurs d’activités différents. L’étude porte sur un total de 108 millions de lignes de code et aboutit à un coût moyen de 2,82 dollars par ligne de code. La taille moyenne des applications de l’enquête était de 374 000 lignes de code, soit une dette technique de plus de 1 055 000 dollars par application.

Au niveau mondial, selon Gartner, la dette IT aurait atteint les 500 milliards de dollars en 2010 et, à l’horizon 2015, ce chiffre serait doublé. Gartner définit la dette IT comme le coût de la maintenance nécessaire pour mettre à niveau les applications afin qu’elles soient « à l’état de l’art ». « Depuis une dizaine d’années, les DSI ont vu leurs budgets réduits, et leur réaction a été de continuer à délivrer la qualité pour leurs services et de proposer de nouvelles fonctionnalités, mais dont la maintenance doit être assurée», note Andy Kite, vice-président de Gartner. Mais cela s’est souvent réalisé au détriment des efforts de maintenance des applications existantes. « Cela ne pose guère de problème si le report des investissements en maintenance ne dure qu’un an ou deux, mais au-delà, les DSI entrent dans une zone de risque », ajoute Andy Kite. Un risque, le plus souvent caché, qui se trouve aggravé en l’absence de gestion de portefeuille applicatif. « La dette technique doit un jour ou l’autre être payée », assure Andy Kite, qui suggère aux DSI de produire, chaque année, un état précis de la dette technique (nombre d’applications existantes, nouvelles, éliminées avec les coûts associés), en identifiant ce qui peut être absorbé ou non…