Développement logiciel : Comment les contrats traditionnels augmentent le risque d'échec

Introduction

En 2007, au Royaume Uni, le DCLG (Department for Communities and Local Government) a signé un contrat avec EADS (European Air and Defence Systems également connu sous le nom Cassidian) pour réaliser un système d'information pour soutenir le projet FiReControl. Ce projet a pour objectif d'améliorer le service d'incendie et de secours du Royaume-Uni en remplaçant 46 centres d'intervention locaux par 9 régionaux. Le projet devait être terminé pour octobre 2009 et le coût estimé par le DCLG était de 120 millions de livres sterling. En 2009, 2 ans après le démarrage, la durée prévue du projet avait doublé et le coût estimé avait augmenté de plus de 500% pour atteindre 635 millions de livres sterling. En 2010 le contrat a été arrêté. La DCLG a gâché au moins 469 millions de livres sterling pour aboutir à un échec¹.

Ce déroulement d'un grand projet d'informatisation qui devient incontrôlable laisse à réfléchir. En fait 2/3 des projets d'informatisation sont livrés en retard ou échouent carrément. De plus 1 projet sur 6 à un dépassement de coût de l'ordre de 200% et un dépassement de planning de près de 70%³. Il apparaît qu'aucune entreprise n'est immunisée contre ces risques. Une croyance était que les projets incontrôlables était l'apanage du secteur public, mais de récentes études montrent que le secteur privé n'est pas meilleur en comparaison. Les sociétés du secteur privé n'ont simplement pas de compte à rendre publiquement et ont du coup la possibilité de dissimuler leurs échecs de projet d'informatisation.

Mais pour quelles raisons les projets d'informatisation sont-ils aussi risqués et comment ce risque peut-il être réduit ?

Le monde du développement logiciel est complètement déconnecté. Les avocats aiment à spécifier les relations entre les différentes parties d'un même contrat autant qu'ils le peuvent. Pourtant le fonctionnel et le développeur travaillent de plus en plus dans un environnement interconnectés, complexe et dynamique.

Les départements juridiques et de gestion n'ont en général pas adapté leurs pratiques ou leur valeurs pour prendre en compte les défis levés par la relation entre fonctionnel et développeur. En fait, le modèle de contrat pour le développement logiciel (le CCTP) et les pratiques de gestion associées ont à peine changé depuis 30 ans. Une grande partie de la pensée qui sous-tend le CCTP remonte aux principes développés lors de la révolution industrielle par des gens comme Henry Ford et Frederick Taylor.

Notre point de vue est que le CCTP aggrave les effets de mauvaise gestion, souvent dus aux concepts erronés du CCTP. Nous avons constaté que même si un projet informatique a les ressources nécessaires en interne, l'entreprise a tendance à mettre en place des relations quasi contractuelles entre le service informatique et les autres services. Et bien sûr, on trouve ici aussi les principes de base du CCTP.

Nous pensons peu probable qu'il y ait une amélioration significative de la réussite des projets informatiques tant qu'aucun changement n'aura lieu au niveau des fondements du CCTP et des pratiques de gestion associées. Dans la suite de cet article nous utiliserons le terme "projet informatique" pour évoquer toute initiative de changement impliquant un développement logiciel.

Les fondamentaux du CCTP

Nous pensons que n'importe quel contrat de développement logiciel basé sur un CCTP contient 3 caractéristiques spécifiques, toutes complétement erronées. Nous utiliserons les termes "fournisseurs" et "client" pour expliquer la dynamique d'une relation entre 2 parties. Cependant, comme précisé plus haut, dans la plupart des cas, les mêmes principes semblent s'appliquer même si l'informatique dispose de ressources internes.

Les 3 caractéristiques spécifiques appliquées, quel que soit le contrat de développement logiciel basé sur un CCTP, sont les suivantes :

• Exigences fonctionnelles de base: Le fournisseur a le devoir de livrer un produit respectant l'ensemble des exigences fonctionnelles spécifiées dans le contrat. Nous utilisons le terme "livrables" pour faire référence au produit (e.g. code, fonctionnalités), documentation et/ou services.
• Mécanismes d'avenants: le CCTP précise que tout changement au niveau des exigences fonctionnelles de base ou de n'importe quel élément du contrat doit faire l'objet d'un avenant. Pour faire simple, pour initier un changement, le client doit soumettre au fournisseur un formulaire décrivant la modification désirée. Le fournisseur analyse l'impact de cette demande de changement au niveau du contrat entier, incluant en particulier les exigences fonctionnelles de base, le prix et la date d'échéance de finalisation du projet. Le fournisseur propose alors un avenant au contrat. Une fois que les 2 parties se sont mises d'accord sur l'avenant, celui-ci est ajouté au contrat pour y inclure la modification.
• Développement séquentiel: le logiciel est prévu d'être développé séquentiellement, soit selon le modèle "waterfall". Le développement coule de façon constante vers le bas, comme une chute d'eau, à travers les phases de conception, initiation, analyse, design, construction et test. Le fournisseur est obligé de terminer chaque phase avant de démarrer la suivante et le livrable de chaque phase fournit le prérequis de la phase suivante.

Il est important de noter que nous ne faisons pas référence au mode de facturation dans le CCTP. Si les trois caractéristiques spécifiques du CCTP figurent dans un contrat, le contrat sera erroné quel que soit le mécanisme de facturation adopté⁴. Il ne fait pas de différence si le prix est fixé, ciblé ou indexé sur le temps et le matériel, ou encore s'il existe des bonus ou des pénalités.

Face à cela ou pour quiconque non impliqué directement dans la mise en oeuvre du projet informatique, le CCTP peut paraître éminemment sensible. Il crée un sentiment de certitude et de prévisibilité par rapport au projet et fournit une vision claire des différentes activités liées au projet informatique. De plus, il reflète les modèles actuels de marchés.

Cependant, la combinaison de ces trois éléments dans une relation contractuelle entre un client et un fournisseur semble provoquer l'échec de nombreux projets informatiques qui réussiraient probablement autrement. En fait, nous pensons que ces projets qui sont finalement couronnés de succès, le sont malgré le CCTP et les pratiques de gestion associés, et non grâce à eux.

Dans cet article, nous analysons les procédés qui font du CCTP un facteur aggravant des risques d'échec d'un projet informatique.

L'aggravation des risques d'échec

Tout projet informatique est soumis à des risques qui peuvent être catégorisés selon trois types :

• Risque de livraison : le risque de ne pas livrer à temps, avec le budget prévu et le niveau de qualité attendu
• Risque sur la plus-value : le risque de ne pas fournir la plus-value attendue
• Risque d'entrave au modèle économique de l'entreprise : le risque que le projet informatique entrave le bon fonctionnement de l'entreprise.

Le CCTP ne s'intéresse pas aux 2 dernières catégories de risque et du coup augmente l'exposition du client aux 3 catégories de risques.

Risque de livraison

Le projet FiReControl est un exemple classique de risque de livraison faisant dérailler le projet informatique. Le bureau national d'audit du Royaume Uni a noté que durant les 2 premières années du contrat, il y a eu de peu de progrès dans la livraison du système informatique⁵. En fait, il apparaît que le DCLG n'a reçu aucun livrable avant que le contrat ne soit terminé. Nous n'en connaissons pas la raison, mais nous pouvons tenter de la deviner.

Les principes obsolètes du CCTP supposent que les exigences fonctionnelles peuvent être prévues dès le départ. Ainsi le principe du CCTP n'arrive pas à répondre correctement aux changements et force le client à engager des frais disproportionnés au regard des retours du projet informatique.

L'illusion que les exigences fonctionnelles peuvent être prévues dès le départ.

L'hypothèse que les exigences fonctionnelles peuvent être prévues dès le départ repose sur 2 autres hypothèses. Premièrement que les exigences fonctionnelles sont comprises par le client et le fournisseur et deuxièmement que le logiciel peut être réalisé avant que tout changement ne survienne. En d'autres termes, pour fonctionner parfaitement, le CCTP suppose que les 2 parties possèdent une information parfaite. Ce qui est pratiquement impossible.

La dynamique même du projet informatique entraine des changements. Il est tout naturel que, lorsque le client en apprend plus sur les avancées technologiques, ses forces et ses faiblesses, celui-ci révise sa réflexion pour exploiter au mieux les avantages de cette technologie.

"...Les exigences systèmes ne peuvent jamais être définies à l'avance, pas même en principe, parce que l'utilisateur ne les connaît pas à l'avance. Affirmer le contraire revient à ignorer le fait que le processus de développement lui-même change la perception de l'utilisateur de ce qui est possible, augmente sa connaissance de l'environnement applicatif et, en fait, change souvent l'environnement lui-même"⁶.

De la même façon, il est naturel que le fournisseur apprenne plus sur le métier, il aura une meilleure compréhension des problèmes que le client essaye de résoudre et les opportunités qu'il cherche à exploiter.

Dans tous les cas, il est impossible d'anticiper comment de nombreux éléments de conception du logiciel interagiront au final et cela amène souvent des surprises.

L'hypothèse selon laquelle le logiciel peut-être terminé avant que des changements apparaissent est aussi erronée. Des forces externes sont en jeu. La technologie évolue à un rythme toujours plus rapide. Le marché ou le contexte dans lequel le concept du logiciel a été conçu évolue. Du coup les opportunités et les risques à traiter par le logiciel évoluent aussi. Par exemple l'émergence des technologies de rupture comme Facebook, Twitter ou les écrans tactiles comme l'iPad ont un énorme impact sur les plans existant de développement et de distribution du logiciel. L'environnement réglementaire peut également changer.

De récentes études, menées par Al Goerner de l'université du Missouri à Kansas City, démontrent que la valeur inhérente aux exigences fonctionnelles s'érode au fil du temps de façon exponentielle. Ce taux de décroissance a été comparé à la demi-vie d'un atome radioactif instable. La demi-vie est la mesure de la période de temps nécessaire à ce que la substance diminue de moitié.

Selon les études menées par l'Université du Missouri, la demi-vie de la valeur des exigences fonctionnelles a diminué rapidement. En 1980, elle était autour de 10-12 ans, en 2000, elle était tombée à 2-3 ans, et elle évolue actuellement aux environs de 6 mois⁷.

En d'autres termes, la moitié des exigences fonctionnelles seront obsolètes au bout de 6 mois, la moitié de la moitié restante (i.e. 1/4) deviendra obsolète au bout de 12 mois et la moitié du quart restant (i.e. 1/8) deviendra obsolète au bout de 18 mois et ainsi de suite. Ainsi à la fin du 18ème mois, selon les études de l'université du Missouri, seulement 1/8 (i.e. 12,5%) des exigences fonctionnelles seront encore valides.

Dans sa volonté de certitude, le CCTP crée finalement le risque que la livraison qui aura lieu ne répondra plus au besoin du client.

L'échec du CCTP à répondre correctement au changement

Si des changements surviennent, le client voudrait pouvoir changer les exigences fonctionnelles. En tant que partie intégrante du contrat, les exigences fonctionnelles ne peuvent être amendées sans qu'un avenant ne soit ajouté au contrat en accord avec les 2 parties selon le mécanisme de gestion des changements. Dans un contrat à prix fixe, les modifications sont souvent considérées comme conduisant à des travaux supplémentaires et le client est tenu de payer des frais supplémentaires. Il n'est pas rare pour le fournisseur de voir un changement comme une occasion d'accroître ses marges.

La première étape du mécanisme de contrôle des changements est que le fournisseur analyse l'impact de la modification demandée par le client. Plus le projet est important et complexe, plus grande est la quantité de travail à fournir par le fournisseur pour accomplir l'exercice. Parfois l'impact du changement demandé est si complexe que le fournisseur n'arrive pas à l'intégrer dans l'existant du projet.

L'analyse de l'impact d'une demande de changement peut être tellement longue et consommatrice qu'elle a un effet déstabilisant sur l'ensemble du projet. L'équipe principale n'est que trop consciente que les travaux en cours peuvent être rendus redondant suite à l'approbation de la demande de changement. Plus le changement est important, plus le hiatus est long durant la phase d'analyse, et plus les effets sont dommageables⁸.

Toute demande de changement va inévitablement entrainer des retards dans le projet. Il est peu probable que le planning initial prévu dans une fenêtre de disponibilité des ressources du fournisseur soit adaptable pour entreprendre des travaux supplémentaires. C'est la raison pour laquelle le client et le fournisseur citent les changements aux exigences fonctionnelles comme la principale raison de l'échec d'un projet informatique.

Pour aggraver les choses, le CCTP impose un développement séquentiel. Ce n'est pas avant les tests que le client peut visualiser le logiciel. Jusqu'à ce moment, il est très difficile pour quiconque de déterminer si le projet informatique est sur la bonne voie. Les livrables de toutes les phases antérieures sont des documents qui sont fondés sur des hypothèses. Ce n'est que lorsque le logiciel est terminé que n'importe qui peut évaluer avec précision si le projet est réellement sur la bonne voie pour répondre aux exigences fonctionnelles. Cependant, il y a un temps important, qui se compte en années, entre la date à laquelle le client perçoit les exigences fonctionnelles et la date à laquelle le fournisseur effectue la première livraison du logiciel. Plus ce temps est long, plus il est probable que des changements importants ont eu lieu pendant la période concernée.

Le risque sur la plus-value

Le projet FiReControl souligne l'importance de prouver dès le début du projet comment celui-ci va apporter de la plus-value et obtenir le soutien de tous. Le DCLG a été critiqué par le bureau national d'audit pour ne pas avoir clairement défini le modèle de centralisation des appels d'urgence et des décisions pour la mise en place des centres de contrôle régionaux. Dès le départ, la plupart des autorités locales de gestion d'incendies et de secours, et leurs services, ont critiqué le manque de clarté sur l'efficacité de l'approche régionale⁹. Même si le logiciel arrive à répondre correctement aux attentes commerciales, le fait qu'il soit correctement conçu ou même sophistiqué n'a aucune importance si les utilisateurs finaux décident de ne pas l'utiliser.

Le risque sur la plus-value, en fait négligé par le CCTP, est bien plus grave. Il existe une croyance supposant que si le fournisseur délivre un logiciel qui répond aux exigences fonctionnelles, il apportera plus de valeur économique au client. Cependant, ceci implique que le client sait ce dont il a besoin. Ce que nous avons découvert, c'est que bien que le client sait ce qu'il veut, il est très souvent loin de savoir ce dont il a besoin. En conséquence, il est courant de voir un client déçu par le logiciel réalisé, même si le fournisseur peut démontrer que celui-ci répond aux exigences fonctionnelles.

C'est une triste mise en accusation de l'état actuel du développement logiciel que de constater que le risque majeur est que le fournisseur conçoit un mauvais logiciel. Ceci arrive à chaque fois que le fournisseur réussit à répondre aux exigences fonctionnelles, mais que le logiciel final n'apporte aucune plus-value au client. Le logiciel n'apporte pas de valeur car il ne permet pas au client de résoudre le problème qu'il cherchait à solutionner.

La raison pour laquelle le client ne tire que peu de plus-value du logiciel réalisé par le fournisseur tient au fait que le CCTP ne fait pas référence aux résultats attendus par le client (ceux-ci même que le client espère voir réalisés et qui lui apporteront une plus-value). Au contraire le CCTP est lié aux exigences fonctionnelles qui définissent les produits qui visent à contribuer et à faciliter l'obtention des résultats attendus.

Les gens achètent un marteau pour planter un clou afin de mettre un tableau au mur, ils savent qu'ils peuvent atteindre leur résultat (mettre le tableau au mur) en achetant un marteau. Malheureusement, dans le contexte du développement logiciel il n'est pas si simple de faire le lien entre le produit délivré (le logiciel) et la réalisation des résultats attendus par le client. La plupart des gens n'essayent même pas. Ceci entraine le risque que le fournisseur délivre ce que le client lui a demandé, à peu près conforme aux exigences fonctionnelles, plutôt que ce dont le client a vraiment besoin, c'est-à-dire d'atteindre les résultats attendus.

Le développement logiciel implique la transformation d'idées en livrables permettant d'atteindre des objectifs économiques. Le catalyseur d'un projet informatique est en général la rentabilité. Le coût prévu du logiciel est justifié par diverses hypothèses telles que l'amélioration des processus internes de l'entreprise, l'augmentation de parts de marché, l'augmentation des revenus, la réduction des coûts de support, etc. Suite à l'approbation interne de l'analyse de rentabilité, les exigences fonctionnelles sont collectées et assimilées par tous ceux dans la société du client qui ont un intérêt à la mise en oeuvre du logiciel.

Du coup si la rentabilité précède la spécification des exigences fonctionnelles pourquoi le logiciel n'arriverait-il pas à chaque fois à répondre aux attentes ?

Premièrement parce que la rentabilité n'est pas vérifiée. Dans la plupart des cas, les analyses sont faites en s'appuyant sur des hypothèses et non sur des faits. Ces hypothèses n'ont pas été validées et il est probable que la plupart sont erronées. Idéalement ces hypothèses doivent être vérifiées avant que des ressources soient investies dans la réalisation d'un logiciel rentable. Mais cela arrive rarement.

Deuxièmement parce que la rentabilité est définie à haut niveau et dans l'objectif d'obtenir des fonds et un budget. Il n'est pas rare de voir des objectifs de rentabilité très ambitieux en termes de fonctionnalités logicielles, cela donne de meilleurs arguments pour convaincre de son acquisition. Il est moins fréquent par contre que la rentabilité joue un rôle actif dans le pilotage de la direction du projet informatique. Il est encore plus rare de revoir les objectifs de rentabilité à la lumière de la progression du projet informatique ou de mesurer l'évolution du projet en faisant référence aux objectifs de rentabilité.

Les conséquences de cela ne peuvent être exagérées. Le Department of Defense (ministère de la défense) est l'un plus importants consommateurs d'informatique au monde, il a un poids non négligeable dans les négociations contractuelles du fait de sa dépense annuelle colossale dans ce domaine. Et pourtant, il ne tire aucune rentabilité directe de ses investissements en développement logiciel. Est-il possible que d'autres sociétés, moins expérimentées, tirent aussi peu de plus-value de leurs dépenses informatiques ?

La méthode la plus efficace pour une société de réduire ses dépenses informatiques est de s'assurer que le logiciel réalisé apportera une plus-value. Nous avons besoin de consciencieusement relier les différentes étapes et de clarifier la manière dont le logiciel apportera le résultat attendu.

L'échec du modèle économique existant

Le CCTP ne s'intéresse pas la possibilité de risque d'échec du modèle économique actuel de l'entreprise. Il n'y a simplement aucune reconnaissance du fait que, dès lors qu'un nouveau logiciel est démarré, celui-ci peut entraver les processus internes existant de l'entreprise. En conséquence le CCTP augmente l'exposition du client au risque d'échec du modèle économique existant, qui est sans doute le plus insidieux des 3 catégories de risques.

Peut-être, dans les années 80s lors des premiers CCTP, les logiciels étaient assez discrets et limités dans leur fonctionnement. Cependant aujourd'hui, les logiciels sont utilisés pour toutes les fonctions de l'entreprise. Il peut y avoir des utilisateurs finaux à différents niveaux de l'entreprise, par exemple la direction financière, le département de comptabilité, la direction marketing, les équipes commerciales et marketing ont tous besoin d'utiliser un même logiciel. Ce logiciel peut interagir avec d'autres logiciels de la société utilisés par d'autres utilisteurs finaux. Le logiciel peut aussi avoir à s'interfacer avec des systèmes d'autres entreprises comme typiquement les clients ou les fournisseurs de l'entreprise.

À la lumière de nombreux processus d'entreprise qui peuvent être impactés par le nouveau logiciel, il est essentiel que la transition vers ce nouveau système soit gérée de manière à réduire le risque d'échec du modèle économique actuel au minimum. Cependant le CCTP requiert en général que toutes les exigences fonctionnelles soient livrées en un seul lot. Plus le projet est important plus la tâche est longue.

Pour de nombreuses entreprises, il est simplement irréaliste de penser que l'assimilation d'un logiciel de cette taille et cette complexité puissent se faire en une fois dans le processus économique existant de l'entreprise. Le risque d'échec de nuire à tous les processus métiers internes, face à d'importants changements, est énorme. Ça se passerait bien mieux si la transition vers le nouveau système était gérée en petites itérations avec un accent sur la qualité de l'expérience utilisateur tout au long de la mise en oeuvre.

Conclusion

De nombreuses études ont été menées pour comprendre les raisons de si nombreux échecs de projets informatiques et pourquoi ils sont si importants. Jusqu'à maintenant le CCTP n'a pas été pris en compte. Nous pensons que le principe du CCTP doit être totalement repensé. Avec l'augmentation de notre dépendance à l'informatique et les coûts croissants des dépenses informatiques, la refonte du principe du CCTP n'est pas prête d'arriver.

Susan et Gabrielle vont prochainement publier un contrat flexible.

¹ ‘The failure of the FiReControl project’ Rapport du controleur et auditeur général du National Audit Office, 1er juillet 2011

³ ‘Double whammy – How ICT projects are fooled by randomness and screwed by political intent’ par Alexander Budzier et Bent Flyvbjerg, essais du Said Business School, Oxford, Août 2011.

⁴ Parfois le CCTP n'impose pas un développement séquentiel mais même si celui-ci ne contient que les spécifications fonctionnelles et les mécanismes de gestion des évolutions c'est tout aussi problématique.

⁵ Voir note 1.

⁶ ‘Lifecycle Concept Considered Harmful’ par Daniel McCracken et Michael Jackson, ACM Software Engineering Notes, Avril 1982.

⁷ Nous n'avons pas pu trouver plus d'informations concernant ces études. Clairement la demi-vie des spécifications variera pour différents secteurs d'activité. Cependant il est acquis que la demi-vie pourrait être encore plus courte dans le secteur technologique.

⁸ ‘The curse of the change control mechanism’ par Susan Atkinson et Gabrielle Benefield, Computers & Law, Mai 2011.

⁹ Voir note 1.

A propos des auteurs

Gabrielle Benefield est PDG de Evolve Beyond et aide les gens à construire d'excellents produits et entreprises. Elle est l'auteur de Scrum Primer et est la co-fondatice de Flexible Contracts avec Susan Atkinson. Elle est actuellement en train d'écrire deux livres sur la livraison de résultats et le HotHousing ; un cadre d'adaptation axé sur les résultats attendus par les entreprises et les utilisateurs, plutôt que les livrables qui créent des déchets et des expériences utilisateurs perturbantes.

Susan Atkinson est avocat-conseil à Keystone Law et co-fondatrice de Flexible Contracts avec Gabrielle Benefield. Elle est avocat d'affaires, spécialisée en informatique, en externalisation, en commerce électronique et en propriété intellectuelle. Elle a plus de 15 années d'expérience juridique et a typiquement travaillé sur des grands contrats à grande valeur commerciale, principalement dans la technologie, les services financiers et le secteur public et souvent dans un contexte international.