Introduction

Dans le domaine des projets informatiques du secteur public, peu d'histoires sont aussi contrastées que celles du National Programme for IT (NPfIT / Programme national pour l’IT) dans le NHS (National Healthcare Service / Service de santé national) et du développement du site web GOV.UK par le Government Digital Service (GDS). Alors que le NPfIT est devenu synonyme d'échec, le projet GOV.UK est souvent salué comme un modèle de réussite de la transformation numérique. Au cœur de ces résultats divergents se trouve une différence cruciale : les méthodologies employées dans leur exécution. La dépendance de NPfIT vis-à-vis du modèle en cascade (cycle en V) a contribué à son échec, tandis que l'approche agile adoptée par le GDS a permis le succès de GOV.UK. Cet article explore les défis et l'échec final de NPfIT et le succès contrasté de GOV.UK à travers le prisme de leurs méthodologies respectives.

Le parcours de NPfIT : une ambition entravée par la méthode en cascade

1. Une grande vision étouffée par la complexité

Lancé en 2002, le NPfIT visait à révolutionner le NHS en numérisant les dossiers de santé, en créant une base de données centralisée des patients et en mettant en place une infrastructure informatique nationale. La portée du projet était vaste, couvrant tous les aspects des opérations du NHS. Cependant, cette grande vision a été entravée par la complexité inhérente à la mise en œuvre d'une solution aussi complète dans une organisation décentralisée comme le NHS.

2. L'approche en cascade : la planification avant l'exécution

Le NPfIT était géré selon le modèle en cascade, une approche traditionnelle de gestion de projet caractérisée par une séquence linéaire de phases : exigences, conception, mise en œuvre, test, déploiement et maintenance. Cette méthodologie exige une planification détaillée en amont et suppose que les exigences du projet peuvent être entièrement comprises et documentées dès le départ.

En pratique, l'approche en cascade a conduit à plusieurs problèmes :

• Retard de la livraison de valeur : Avec la cascade, la majeure partie de la valeur est livrée à la fin du projet. Pour NPfIT, cela signifiait que des années se sont écoulées avant que des systèmes utilisables ne soient disponibles, entraînant la frustration des parties prenantes.
• Inflexibilité au changement : Les besoins du NHS ont évolué avec le temps, mais la structure rigide de la cascade rendait difficile l'adaptation aux nouvelles exigences sans un réaménagement et des retards significatifs.
• Accumulation des risques : En reportant les tests et la validation à des étapes ultérieures, les problèmes s'accumulaient sans être remarqués jusqu'à ce qu'il soit souvent trop tard pour les résoudre sans coût et effort considérables.

3. Centralisation contre besoins locaux

Le NPfIT imposait une solution unique à des entités diverses du NHS, dont beaucoup avaient des exigences spécifiques. Cette approche descendante entrait en conflit avec les besoins locaux, entraînant résistance et difficultés de mise en œuvre. Le manque de boucles de rétroaction itératives du modèle en cascade a encore aggravé cet alignement défaillant.

4. Dépendance aux fournisseurs et obstacles techniques

La forte dépendance du NHS envers un petit nombre de grands fournisseurs informatiques signifiait que lorsque ces fournisseurs ne livraient pas comme promis, tout le projet en souffrait. Les défis techniques, tels que l'intégration de systèmes disparates et l'assurance de l'interopérabilité, étaient exacerbés par la nature séquentielle du modèle en cascade, qui laissait peu de place à la résolution itérative des problèmes.

5. Dépassements financiers et opérationnels

Initialement budgétisé à 6,2 milliards de livres sterling, le coût du NPfIT a grimpé en flèche, avec des estimations suggérant que les dépenses finales dépassaient les 10 milliards de livres. Les délais prolongés et les dépassements de coûts, combinés à l'absence de bénéfices tangibles, ont conduit à une critique croissante. Finalement, le NPfIT a été démantelé en 2011, avec une grande partie de sa vision ambitieuse non réalisée.

GOV.UK : l'agilité en action

1. Une approche itérative centrée sur l'utilisateur

À l'opposé du NPfIT, le développement du site web GOV.UK par le GDS illustre les avantages des méthodologies agiles. Lancé en version bêta en 2011 et pleinement opérationnel en 2012, GOV.UK visait à simplifier et centraliser les services gouvernementaux en ligne, les rendant plus accessibles au public.

2. Méthodologie agile : flexibilité et livraison continue

Les méthodologies agiles mettent l'accent sur le développement itératif, les versions fréquentes et les retours d'information continus des utilisateurs. Cette approche a permis à l'équipe GDS de :

• Livrer de la valeur incrémentale : En travaillant par courtes itérations et en publiant régulièrement des mises à jour, GOV.UK a immédiatement apporté de la valeur aux utilisateurs. Les premières versions du site étaient fonctionnelles et répondaient aux besoins critiques des utilisateurs, avec des améliorations ajoutées progressivement.
• S'adapter aux changements : La flexibilité de l'agile a permis à l'équipe GDS de répondre rapidement aux exigences changeantes et aux retours d'information. Cela a été crucial pour affiner le service en fonction de l'utilisation réelle et des attentes évolutives des utilisateurs.
• Réduire les risques par l'itération : Les tests et la validation continus ont minimisé le risque d'échecs majeurs. Les problèmes ont été identifiés et résolus tôt dans le cycle de développement, les empêchant de devenir des obstacles critiques.

3. Autonomisation des petites équipes pluridisciplinaires

Le succès de GOV.UK a également été favorisé par la focalisation du GDS sur des équipes petites et autonomes. Ces équipes pluridisciplinaires ont été habilitées à prendre des décisions rapides et à itérer fréquemment. En combinant les compétences de développeurs, de concepteurs, de rédacteurs de contenu et d'analystes de données, ces équipes étaient capables de créer des solutions innovantes et adaptées aux besoins des utilisateurs.

Cette approche contrastait fortement avec le style de gestion centralisé et descendant du NPfIT. En permettant à chaque équipe de se concentrer sur des objectifs spécifiques et mesurables, GOV.UK a pu accélérer le développement et l'amélioration continue de ses services, en restant aligné sur les attentes et les exigences changeantes des utilisateurs.

4. Focalisation sur les besoins des utilisateurs

Dès sa conception, GOV.UK a été conçu en pensant à l'utilisateur. L'équipe GDS a donné la priorité à la compréhension et à la satisfaction des besoins des citoyens et des entreprises, aboutissant à un service intuitif et accessible. Cette approche centrée sur l'utilisateur a permis au projet de livrer une véritable valeur, contrairement à la focalisation plus bureaucratique de NPfIT.

La méthodologie agile a permis au GDS de recueillir régulièrement des retours d'information et d'apporter des améliorations continues basées sur les besoins réels des utilisateurs. Par exemple, l’équipe a utilisé des tests utilisateurs et des analyses de données pour ajuster rapidement les fonctionnalités et l'interface du site, garantissant que le service restait utile et pertinent.

5. Efficacité des coûts et rapidité

L'approche agile de GDS a non seulement permis de livrer un produit fonctionnel plus rapidement, mais a également maintenu les coûts sous contrôle. GOV.UK a été développé pour une fraction du budget de NPfIT et en un temps beaucoup plus court, démontrant comment les méthodologies agiles peuvent favoriser l'efficacité dans les projets informatiques du secteur public.

En favorisant des cycles de développement courts et des livraisons fréquentes, le GDS a pu itérer rapidement et apporter des ajustements en temps réel, minimisant ainsi le risque de gaspillage de ressources. De plus, la capacité à répondre rapidement aux changements a permis de réduire les coûts liés aux révisions tardives et aux ajustements de dernière minute, souvent coûteux dans les projets en cascade.

Conclusion

Les histoires contrastées de NPfIT et de GOV.UK soulignent le rôle crucial des méthodologies de gestion de projet dans la détermination du succès des projets informatiques à grande échelle. La dépendance de NPfIT au modèle en cascade a conduit à des retards de livraison de valeur, à une inflexibilité et à un échec final, malgré des investissements significatifs. En revanche, l'approche agile de GOV.UK a permis un développement rapide et centré sur l'utilisateur, une amélioration continue et une livraison rentable.

Alors que les organisations du secteur public continuent d'entreprendre des parcours de transformation numérique, les leçons tirées de NPfIT et de GOV.UK soulignent l'importance d'adopter des méthodologies qui privilégient la flexibilité, le développement itératif et la livraison de valeur précoce et continue. Le succès de GOV.UK démontre que les méthodologies agiles ne sont pas seulement une alternative à la mode, mais un cadre éprouvé pour atteindre une transformation numérique durable et impactante.