Pourquoi tant de projets informatiques échouent ?

Interview de Nathan Y. HATTAB

Nathan Y. HATTAB est consultant en système d’Information. Il est Expert en Informatique près la Cour d’Appel et la Cour Administrative d’Appel de Paris. Spécialiste du management des projets informatiques, il côtoie leur pathologie.

Les projets informatiques ont souvent mauvaise presse, quelles sont de votre point de vue, les 5 écueils majeurs que vous rencontrez ?

Il y a aussi des projets qui réussissent, même avec un léger dérapage. Mais vous avez raison, de nombreux projets dérapent de façon importante ou coulent avant d’arriver au port. Les écueils à l’origine de ces échecs sont multiples mais on peut retenir en premier lieu l’inexpérience du chef de projet ou son incapacité à conduire son projet. Ensuite, il y a l’imprécision du cahier des charges, le manque de maturité du client, le manque de maîtrise des processus de l’ingénierie du logiciel du prestataire ou les mauvaises estimations de la charge du projet. Mais, bien souvent il y a concomitance de facteurs. Un chef de projet expérimenté qui maîtrise les techniques d’estimation de charges, identifiera des imprécisions du périmètre fonctionnel et posera les questions adéquates. L’imprécision du cahier des charges est une véritable plaie. Dans certains cas, elle donne au client l’illusion de disposer de plus de temps pour mieux préciser ses besoins encore flous et peut-être d’en avoir plus pour le même prix. Quant au prestataire, il peut aussi y trouver une porte ouverte à la signature de nouveaux avenants.

Je suis conduit à me pencher sur de nombreux projets bâtis sur des technologies et des démarches variées, en UML ou en Merise, avec des postes clients dotés de navigateurs accédant à des sites Web ou d’écrans noirs avec des caractères verts, des langages avec ou sans balise, des environnements de développement variés ... Les dossiers qui me sont soumis et qui décrivent les exigences des logiciels continuent à porter les mêmes noms : spécifications générales ou détaillées avec parfois la précision de fonctionnelle et/ou technique. Pour les progiciels intégrés, l’éditeur d’ERP dispose de sa propre méthode de conduite de projets et de son propre vocabulaire. Ces méthodes présentent différentes particularités. Elles comportent une étude d’adéquation qui permet de rapprocher les besoins du client aux fonctionnalités du progiciel et ainsi de décider d’une adaptation de l’organisation au produit ou l’inverse. Elles proposent aussi un maquettage des processus de l’entreprise et des fonctionnalités du produit ainsi qu’une étape de prototypage par paramétrage et validation par le client. Le problème du vocabulaire n’est pas nouveau en conduite de projet. Il suffit pour s’en convaincre de se pencher sur les méthodes et les normes en ingénierie du logiciel pour constater la multiplicité des termes employés pour désigner les mêmes étapes des projets informatiques.

Dans les grandes entreprises, la maîtrise d’ouvrage semble avoir pris plus d’assurance et plus de tonus. Elle n’hésite pas à se faire accompagner par des assistants internes ou externes pour palier son indisponibilité voire son manque de compétence. Mais quand on se penche sur les projets qui se plantent, on identifie souvent les mêmes maux résultant en partie de la maîtrise d’ouvrage : un cahier des charges insuffisamment précis et une exigence excessive de la maîtrise d’ouvrage vis-à-vis de maître d’œuvre lors de la validation des spécifications fonctionnelles. Elle a rarement en tête la règle des 80/20. Elle exige tout, même lorsqu’elle est à l’origine de l’imprécision initiale fautive et condamne de ce fait le projet. La maîtrise d’œuvre n’est pas non plus sans reste. Elle n’investit pas toujours suffisamment sur le métier du client et ne dispose pas constamment du chef de projet à la hauteur de la tâche.

On parle parfois de partenariat, de win / win, quel sens donnez-vous à cette relation entre intégrateur et client ? La réussite d’un projet se bâtit par le partenariat, ce qui implique une maturité du client comme du prestataire qu’il soit ou non intégrateur. Dans cette situation, la maîtrise d’ouvrage est à même de comprendre la préoccupation du prestataire qui souhaite restreindre parfois certaines exigences fonctionnelles ou techniques. Elle a en contre partie l’assurance du respect de la livraison d’une version plus restreinte mais opérationnelle. Dans des situations extrêmes, dans une relation de gagnant/perdant, le désaccord peut atteindre un tel niveau de tension que la collaboration cesse. Un prestataire peut arriver à la conclusion qu’il vaut mieux quitter un projet sans être payé que le mener au bout et d’y laisser encore plus de plumes. Il est possible dans certains cas, d’éviter de tels litiges par la contractualisation de la taille du projet en points de fonction. Si le périmètre devait évoluer, il suffirait de coter la taille du produit réalisé pour mesurer l’écart entre le prévu et le réalisé.

Le non respect de quelques principes simples porte évidemment en elle-même les germes de l’échec. Dissocier par exemple le cycle de la validation des livrables de celui des échéances de paiement peut être complètement néfaste. Un client ne peut admettre que l’échéancier des paiements reste immuable alors que le projet dérive et que les livrables ne lui sont pas fournis. Plusieurs procédures indispensables au bon déroulement des projets doivent avoir été prévues contractuellement, faute de quoi elles peuvent être écartées par l’un des partenaires. Si ces procédures ont été prévues dans le contrat ou dans le plan d’assurance qualité associé, elles favoriseront le succès du projet.

Comment peut-on maîtriser la relation triangulaire intégrateur / éditeur / client ? Faut-il exiger un groupement conjoint ?

Le client ne doit surtout pas se transformer en coordonnateur de l’intégrateur et de l’éditeur. Il doit rechercher un interlocuteur unique, un intégrateur compétent et "certifié". La certification de l’intégrateur devrait relever tant de l’éditeur que des organismes professionnels. Le groupement conjoint est basé sur des accords de cotraitance et un partage du périmètre contractuel entre l’éditeur et l’intégrateur. Mais en cas de problème, les cotraitants se renvoient souvent la balle et le client n’a pas la compétence requise pour diagnostiquer la véritable cause de la situation.

Que pensez-vous de la sacro-sainte obligation de résultat ? n’est-ce pas un vœux pieux qui risque d’être balayé dès que la maîtrise d’ouvrage a le moindre manquement à ses obligations, c’est-à-dire très vite ?

L’obligation de résultat a pour origine les engagements contractuels de réaliser un produit ou une prestation répondant à des exigences fonctionnelles et techniques données pour un coût et un délai alloués. Elle concerne les opérations d’informatisation dites au forfait qui nécessitent une définition précise du périmètre fonctionnel et technique du projet. Bien entendu, toute demande d’évolution de ces exigences de la part de l’un des partenaires déclenche une procédure pour en évaluer les conséquences en terme de coût et de délai. L’accord des parties sur cette évaluation conditionnera sa prise en compte. Cela suppose aussi le respect par la maîtrise d’ouvrage de ses obligations et en particulier de son obligation de collaboration. Dans de nombreux litiges, le prestataire met en cause la collaboration de son client pour camoufler ses propres défaillances et inversement le client est conduit pour escamoter ses manquements, à reprocher au prestataire son incompétence technique ou d’avoir failli à son obligation de conseil. Dans le monde du Bâtiment et des Travaux Publics, qui a beaucoup inspiré celui des systèmes d’information, à l’issue des projets qui dérivent en terme de délai et de coût, le prestataire présente de plus en plus souvent un mémoire de réclamations. Dans ce mémoire, il demande à être dédommagé des surcoûts résultant des décisions ou des non décisions de la maîtrise d’ouvrage. On y viendra aussi avec les systèmes d’information.

Quelle durée peut-on tolérer, dans un projet au forfait, entre deux actions de vérification ? Le risque de dérive est-il croissant avec la durée du projet ?

Les opérations de validation et de vérification sont normalement planifiées en début de projet. Certaines de ces opérations sont réalisées par le prestataire indépendamment de son client, c’est le cas des opérations de relecture ou de revue interne, préalablement à la production d’un livrable. Ces opérations sont inscrites dans le Plan d’Assurance Qualité qui contient les principales obligations du prestataire en matière de qualité. La validation du client porte sur les livrables sous forme définitive ou provisoire. Le client dispose de feuilles de relecture pour signaler les incomplétudes, les inconsistances, les incohérences et les autres non conformités d’un dossier de spécifications fonctionnelles. Des réunions de revue conjointe sont tenues pour permettre aux partenaires de disposer d’une vision commune de l’avancement du projet. Ces opérations conjointes sont planifiées et se traduisent par des actions d’ajustement qui feront l’objet d’un suivi rigoureux de la part du chef de projet.

Les risques de dérives croissent bien entendu avec la complexité du projet. C’est la raison pour la quelle, le manque de qualité et de maîtrise technique ne peuvent pas y être tolérées.

La planification est-elle sérieusement gérée et actualisée, d’une façon générale ?

Les projets qui se plantent font aussi l’objet d’une planification mais elle est souvent tardive ou basée sur une analyse incomplète des exigences fonctionnelles. La planification sérieusement gérée suppose une identification précise de ses processus, de ses activités de ses tâches et de ses ressources, mais aussi une maîtrise préalable des estimations de charges de développement. Sans ces préalables, elle ne peut aboutir qu’à un planning glissant sans lien avec la réalité du projet. Le planning est un outil indispensable au suivi du projet. Son actualisation est indispensable sinon il ne sert plus à rien.

S’agissant des processus de la DSI, pensez-vous qu’ils soient suffisamment définis et maîtrisés : achats, vérification, recette, gestion des changements, déploiement ?

Un projet informatique complexe aura de grandes difficultés à réussir dans une organisation dépourvue de procédures et de culture des systèmes d’information. Il est difficile de déployer une approche de qualité dans une entreprise qui en est dénuée. L’identification, la formalisation et la maîtrise de ses processus est une exigences de l’assurance qualité. Les DSI des grandes entreprises que je côtoie investissent dans cette voie.

Certains de ces processus comme la gestion des changements sont relativement bien identifiés et maîtrisés. D’autres comme les processus de vérification, de résolution de problème, de management des risques ou de projet sont à des stades très variés d’une entreprise à l’autre.

Où en sont les normes ? croyez-vous à l’ISO 9001 V2000, quelle est l’influence de SPICE ? Observez-vous des règles différentes dans les DSI de groupes anglo-saxons, par exemple ?

Il y a bien sûr l’ISO 9001 version 2000, mais aussi SPICE (ISO 15.504) qui procèdent de la même logique, c’est-à-dire identifier et appliquer des procédures mais aussi s’assurer de la satisfaction du client par la mesure de la qualité. Cette mesure de la satisfaction du client s’accompagne de l’engagement du management à surveiller et à améliorer en permanence la qualité.

J’ai vu à plusieurs reprises des projets échoués alors que le prestataire de service était certifié ISO 9001 version 1994. Il disposait d’un plan d’assurance qualité décrivant les différents processus et les procédures de qualité qu’il s’engageait à appliquer. Il s’agissait en fait de pré-requis nécessaires à la réussite du projet mais pas suffisants même lorsqu’ils semblaient être respectés.

Avec l’ISO 9001 V2000, la préoccupation du management va au-delà de l’application des procédures. Mais il faudra se préoccuper de la pertinence des indicateurs de mesure de la qualité des produits et des processus qui devront être mis en place.

Quant aux DSI et aux prestataires anglo-saxons que j’ai observés, ils sont peu nombreux mais ils étaient plus enclins à suivre les recommandations du CMM, qu’à décrocher une certification ISO 9001.

Certains organismes (PMI, AFITEP) mettent en place une certification des chefs de projet, pensez-vous que cela soit nécessaire ? sur quels champs ? comportement, leadership, maîtrise des techniques d’évaluation et de gestion des ressources, communication ?

Faudra-t-il faire passer un permis de conduire au chef de projet ? Et si oui sur quels champs ?

Mon premier constat est qu’un chef de projet qui n’a ni les compétences, ni les qualités requises, a de fortes chances de se planter. Il faut dès lors former les chefs de projet.

Comment, par qui et sur quels champs ? Comme toute formation, elle devrait être conduite et sanctionnée par une autorité reconnue comme par exemple l’Université ou les organismes représentatifs de la profession.

Quant au champ de la certification, il devrait concerner la conduite de projet, les normes, le système qualité, les domaines fonctionnels et techniques mais aussi les aspects contractuels. Bien entendu, il devra aussi porter sur la capacité d’écoute, de synthèse, d’animation et de motivation, le sens de l’anticipation, de la communication mais aussi de la rigueur.

La certification des chefs de projets informatiques sera un symptôme révélateur de la maturité des métiers de l’informatique et des systèmes d’information.