IUT Dijon /IQ-S3/ Management de l’informatique / 2006-2007
S3. Management de l’informatique
Thème n°4. LA QUALITE DES PROJETS INFORMATIQUES. Synthèse : éléments de correction
Question 2. A partir du document 2 et pour conclure cette première partie des enseignements, rédigez une synthèse1 relative à la qualité des projets informatiques : Pour cela, efforcez-vous de répondre aux questions suivantes et d’illustrer votre propos (par des exemples trouvés sur le net2) :
La notion de projets informatiques est large : quoi de commun a priori entre un projet de 3 mois à budget réduit ayant pour objet une application simple de facturation pour PME par exemple, un projet d’intégration de progiciel de gestion de 5 ans (au budget conséquent) ou d’édition d’une nième version du système d’exploitation équipant plus de 90% des PC ? Les enjeux en termes de qualité sont à l’évidence croissants avec la complexité du projet informatique. Cependant, assurer la qualité d’un projet informatique, quel qu’il soit, semble aujourd’hui « aller de soi ». Les nombreux échecs (ou réussites mitigées), très coûteux pour les entreprises qui en supportent les conséquences sont bien entendu à l’origine de cette prise de conscience relativement récente.
- Pourquoi la qualité des projets informatiques3 est-elle une préoccupation relativement récente ?
o Le management de la qualité est récent : il est issu des interrogations des industries spatiales &
aéronautiques principalement (1970). Celles-ci portent sur des « gros » projets. Dans les années 1980, le JAT introduit la notion de qualité totale dans les industries de biens d’équipement automobile (Toyota), électronique (Sony)… Aujourd’hui, elle concerne tous les secteurs (normes ISO9000 et suite), services compris. Or, l’informatique est lui-même un secteur relativement récent : la qualité totale s’y est donc imposée rapidement.
o La qualité des projets informatiques est l’héritière de ces évolutions récentes. Le contexte économique a changé pour les entreprises informatiques, en particulier pour les SSII maître d’œuvre de projets pour le compte de leurs clients, comme pour ces clients eux-mêmes. La compétition mondialisée a favorisé la mise en œuvre de grands projets d’investissements informatiques, d’ « informatisation » des entreprises, puis de « rationalisation » des systèmes informatiques. Compte tenu de l’importance croissante des ressources financières consacrées à l’informatique par les entreprises utilisatrices, désormais, les projets informatiques doivent être performants du point de vue technologique comme du point de vue économique. Les entreprises clientes attendent un « retour sur investissement » élevé des dépenses initialement consenties. La maîtrise des délais & des budgets devient impérative (or les échecs ou réussites « mitigées » restent importants - cf TD1 - !). Aussi, la qualité de ces projets devient le critère premier de jugement de la réussite ou de l’échec d’un projet, cette « qualité » recouvrant tous les aspects de la « bonne marche » d’un projet : qualité de la négociation avec le client (PAQ), qualité d’organisation du MOE, qualité des méthodes de développement mises en œuvre, repérage & mise en œuvre des
« bonnes pratiques », qualité de la formation du personnel…
Bien entendu, on ne saurait nier les spécificités des projets informatiques ayant des incidences sur la qualité des projets informatiques.
- En quoi la qualité des projets logiciel est-elle plus problématique ou plus complexe que celle des projets industriels par exemple ?
1 Une réponse structurée avec une courte introduction (la problématique) et une conclusion vous permettant d’exprimer un point de vue par exemple.
2Voir notamment :
http://www.mines.u-nancy.fr/~tisseran/cours/qualite-logiciel/qualite_logiciel.html Mais aussi des revues en ligne telles que : www.01net.com
3 Vous pouvez restreindre votre étude aux projets de système d’information ou projets logiciel à l’instar de C. Morley
Patricia Renardet Page 1 sur 3
IUT Dijon /IQ-S3/ Management de l’informatique / 2006-2007
o Le caractère immatériel des projets informatiques pose un problème spécifique : la qualité totale implique de ne pas se contenter d’une bonne conformité du produit au standard préétabli ; elle implique une réflexion ambitieuse sur le processus (conception, production…) qui conduit au produit fini. En matière de développement, la distinction entre produit & processus n’est pas pertinente : la qualité du programme est celle de son développement. C’est pourquoi, par exemple, les « ateliers de génie logiciel » se développent : repérer les meilleures méthodes de développement réduit le coût lié à la non-qualité des projets informatiques (si la qualité coûte cher, la non-qualité coûte davantage encore !). Cela dit, à l’instar des projets industriels, plus une erreur est corrigée tôt dans le cycle de vie du projet, moins elle est coûteuse (graphiques projets IBM).
o Il est cependant opportun de faire la distinction entre 2 types de projets (et de marchés) informatiques : 1°) Les progiciels sont proches des caractéristiques des projets industriels, avec cette spécificité que le coût de reproduction est marginal. L’éditeur doit impérativement assurer la qualité du développement initial pour assurer sa rentabilité (une erreur est susceptible d’être reproduite « infiniment »). 2°) La qualité du développement spécifique d’un programme pour un client repose avant tout sur la satisfaction de ses besoins (d’où la définition de l’Afnor). A noter que les projets d’intégration des PGI impliquent les 2 ! A la limite chaque projet est unique (non- reproductible) : par conséquent, la recherche de la qualité totale n’en est que plus difficile !
A défaut d’être facile à spécifier, la qualité n’a qu’un seul juge : le commanditaire (le client / le consommateur potentiel pour les progiciels).
- Un projet peut-il, en général, respecter simultanément tous les facteurs & critères de qualité ? Qui doit alors définir ceux-ci, contrôler leur respect ?
o Le modèle facteurs/critères/ métriques (et la norme ISO 9126) s’efforce de spécifier la qualité totale d’un projet informatique. D’abord, implicitement, il traduit une clarification des responsabilités entre MOA & MOE. Le MOA est juge de la qualité du produit : il définit les spécifications attendues (capacité fonctionnelle…) et ses attentes à l’égard de l’application informatique commandée (réduction des coûts d’utilisation du système d’information, amélioration des performances…). A charge pour le MOE d’assurer la qualité du processus. Bien entendu, les 2 parties doivent coopérer : le MOE, par ses compétences en informatique, est le mieux placé pour aider le MOA à expliciter ses besoins (la facilité d’utilisation par exemple dépend beaucoup des solutions proposées par le MOE) et le MOA, comme futur utilisateur, doit veiller à ce que le projet
« reste dans les clous » du CC initial (ou pour faire évoluer ce CC).
o Cependant, la qualité globale ou totale n’implique pas le respect de tous les critères qualité : 1°) certains facteurs sont contradictoires entre eux 2°) puisque le plus important est de répondre aux exigences du client, c’est avec celui-ci qu’il faut établir la hiérarchie des critères (quels sont ceux que l’on écarte ? ceux qui sont jugés prioritaires ?) et les spécifier dans le PAQ (et donc le CC).
Les « métriques » sont des moyens de mesurer, de manière objective, l’atteinte d’un critère qualité (ex : la fiabilité par un taux de « panne » inférieur à 5%).
- Quel diagnostic, une entreprise gérant ses projets de systèmes d’information peut-elle faire grâce au modèle « CMMI » ? (faites une courte recherche sur ce modèle si besoin) ?
o La qualité totale est un objectif idéal difficile à atteindre, qui ne se « décrète pas ». Les démarches qualité sont devenues la règle, notamment la recherche d’une certification ISO par les « grandes » SSII (qui ne peuvent pas répondre à certains appels d’offre sans cela) comme par les services informatiques de « grandes entreprises » (la certification incluant tous les « métiers »), mais le bon ou mauvais diagnostic qui ressort de ces démarches (on obtient ou pas une certification ISO, on la garde ou la perd au bout de 3 ans…) n’est pas suffisant.
o Aussi, la démarche CMM-I relève du principe d’amélioration continue. Définie pour les entreprises de développement logiciel, elle offre la possibilité non seulement de diagnostiquer le « degré de maturité » actuel de leurs systèmes d’information, mais leur permet de définir une politique
Patricia Renardet Page 2 sur 3
IUT Dijon /IQ-S3/ Management de l’informatique / 2006-2007
d’amélioration progressive de ceux-ci vers un niveau supérieur. Ce principe d’amélioration continue a été vulgarisé par Deming sous la forme d’une roue (voir PDCA ou roue de Deming.doc) et traduit le fait qu’une entreprise doit être capable de tirer les leçons du passé pour ne pas les reproduire et identifier les « bonnes pratiques4 » pour les capitaliser et former son personnel à leur maîtrise. En matière de développement, cela se traduit par une réduction des risques d’échec des projets informatiques au cours du temps. Cependant, conformément à la qualité totale, une entreprise ne saurait « réserver » cette démarche aux seuls processus informatiques : à quoi serviraient de tels efforts si la gestion des ressources humaines ou financières est défaillante ? C’est pourquoi la méthode CMM-I, comme la démarche ISO, peut impliquer l’ensemble des processus de l’entreprise.
- Selon A. Lefebvre, pourquoi faut-il privilégier une démarche corrective plutôt que préventive pour les projets informatiques (et donc quelles sont les limites des méthodes décrites précédemment) ?
o Pour A. Lefebvre, la recherche de « la » méthode de développement logiciel est erronée ; elle est semblable à la recherche du « one best way » de Taylor en matière d’organisation industrielle (appliquée par Ford). Les méthodes doivent être appliquées avec recul et discernement : elles sont des repères pour les développeurs. Elles traduisent les exigences que les entreprises sont en droit d’attendre de leurs salariés : professionnalisme, rigueur… ; elles sont le fruit de l’expérience et des pratiques antérieures car il est normal de ne pas reproduire les erreurs passées comme de ne pas
« réinventer la roue »… mais ces méthodes ne sauraient remplacer une bonne gestion des ressources humaines, un bon plan de formation des équipes.
o Surtout, ces méthodes ne sauraient ignorer une spécificité du développement logiciel : déboguer fait partie du « métier » ; il n’est pas anormal en soi qu’un programme ne soit pas « bon à 100% » si l’équipe de développeurs est en mesure de corriger ses erreurs sans dommage pour l’utilisateur de l’application ; le développement est un processus risqué, il faut l’admettre, à charge pour les développeurs de gérer ce risque. De même, la maintenance évolutive fait partie du « cycle de vie » d’une application logicielle. Aussi, la maintenance corrective (essai/erreur/correction) a toute sa place, la démarche préventive admettant des limites techniques (on apprend de ses erreurs) et économiques (un produit peut être jugé « bon » s’il satisfait le client même s’il n’est pas portable sur d’autres SI, ce qu’une version ultérieure permettra par ex). Reste à faire admettre au client que la « facture » liée à la maintenance de ses systèmes d’information est justifiée !
L’exigence de qualité des projets informatiques a des incidences sur les qualifications attendues par les entreprises de leurs informaticiens, la qualité totale reposant sur une implication de tous les salariés.
Aucune méthode, aussi élaborée soit-elle ne saurait remplacer de « bon » développeurs : bon techniciens, il doivent aussi développer des aptitudes en communication, être capables de s’adapter à différents contextes d’entreprise tout en faisant preuve de discernement vis-à-vis des méthodes qu’ils mettent en oeuvre5… Bref, tout un programme !
4 Par exemple, font partie des « bonnes pratiques »les méthodes de rédaction d’un CC, de planification efficace d’un projet, de documentation détaillée des compte rendus de réunions avec le client assurant la traçabilité des décisions prises…
5 Note : processus d'assurance qualité, Ecrivez ce que vous faites - Faites ce qui est écrit - Prouvez que vous le faites
Patricia Renardet Page 3 sur 3
