Dans les grandes sociétés, les services informatiques ont chacun leurs objectifs, MOA, développement-études, production, et dépendent d’une DSI dans laquelle la qualité n’est pas gérée de manière transverse. Pour beaucoup encore, faire de la qualité, c’est faire des tests fonctionnels avant livraison en production. Plus les anomalies sont détectées en tests, plus les budgets de développement augmentent… Pourquoi ne pas utiliser ces enveloppes pour industrialiser la qualité logicielle sur tout le cycle de développement, et même sur le cycle de vie du système d’information ?
Une fois le système mis en production, les activités de gestion des incidents prennent le relais, et sont assurées par des personnes n’ayant pas de périmètre d’action au niveau des développements. Pourquoi ? Parce que les budgets sont différents. Certains considèrent que si des anomalies logicielles surviennent, c’est que le processus de fabrication est défectueux. Or le processus de fabrication logicielle est souvent une suite d’activités indépendantes non pilotée par la qualité.
Dans certains appels d’offres, les missions de Tierce Recette Applicative et de Tierce Maintenance Applicative sont séparées, ce qui n’est malheureusement pas toujours le cas. Mais même dans ce cas, il manque le pilotage transverse de la qualité et l’on peut voir les deux entités “s’étriper” au lieu de travailler ensemble à l’élaboration d’un processus industriel.
Aujourd’hui, la qualité logicielle pâtit de mises en production de systèmes non conformes aux besoins du client. Peut-être certains préfèrent prendre ou cacher ce risque plutôt que d'informer et de décider de retards dans la planification ?
