Pourquoi 70% des projets SI en milieu hospitalier dérivent (et comment l’éviter)
- Les six causes structurelles qui expliquent ces dérives dans le contexte hospitalier
- Ce qui distingue les projets qui réussissent de ceux qui échouent
- La méthode d’analyse préventive applicable à tout projet SI de santé en Suisse
La dérive des projets SI hospitaliers n’est pas une fatalité
Quand un projet SI hospitalier dérape, la réaction naturelle est d’en chercher la cause dans l’exécution : le prestataire a mal livré, le planning était irréaliste, les équipes ont résisté. Ces facteurs existent, mais ils sont rarement la cause première. Ils sont les symptômes d’un problème de conception qui remonte à la phase de cadrage.
Le Standish Group identifie trois facteurs principaux de succès des projets IT depuis 1994 : l’implication des utilisateurs, le soutien de la direction, et la clarté des exigences fonctionnelles. Ce sont précisément ces trois facteurs qui font défaut dans les projets hospitaliers qui dérivent.
Les institutions qui réussissent leurs projets SI ne disposent pas de budgets plus importants, de prestataires plus compétents ou d’équipes plus coopératives. Elles partagent une caractéristique commune : elles ont investi du temps et des compétences dans l’analyse avant de construire. Elles ont diagnostiqué avant d’agir.
Le secteur de la santé présente des caractéristiques qui rendent cette discipline particulièrement critique : multiplicité des parties prenantes, contraintes de continuité de service absolues, exigences réglementaires strictes, et populations d’utilisateurs aux profils très hétérogènes. Dans ce contexte, une spécification incomplète coûte dix fois plus cher à corriger en phase de déploiement qu’en phase de cadrage.
Les six causes structurelles de dérive
1. Des besoins recueillis sans les utilisateurs terrain
C’est la cause la plus fréquente et la moins visible jusqu’au déploiement. Les besoins sont recueillis auprès des directeurs de service, des chefs de pôle et des responsables IT. Ces interlocuteurs connaissent les processus tels qu’ils devraient fonctionner. Ils ne connaissent pas toujours les processus tels qu’ils fonctionnent réellement dans les unités opérationnelles.
Une infirmière de nuit, un technicien de laboratoire, un secrétaire médical : ces utilisateurs ont des contraintes de travail spécifiques, des raccourcis informels, des besoins non formulés que personne n’a jamais documentés. Quand le nouveau SI ignore ces réalités, les utilisateurs développent des contournements, et le taux d’adoption reste structurellement bas.
2. Des contraintes réglementaires intégrées trop tard
En milieu hospitalier suisse, les projets SI sont soumis à un cadre réglementaire dense : LPD, normes de sécurité des données de santé, exigences d’auditabilité, règles de conservation des dossiers patients, conformité aux standards d’interopérabilité (HL7, FHIR). Ces contraintes doivent figurer dans les spécifications fonctionnelles dès le début du projet, pas être ajoutées comme une couche de conformité en fin de développement.
Quand un système est conçu sans intégrer ces contraintes dès l’architecture, leur ajout a posteriori nécessite des modifications structurelles coûteuses. Dans le pire des cas, certaines fonctionnalités doivent être entièrement reconçues pour satisfaire aux exigences réglementaires que personne n’avait formalisées dans le cahier des charges.
3. Une gestion de projet sans Business Analyst
La confusion entre le rôle de chef de projet et celui de Business Analyst est particulièrement coûteuse dans les projets hospitaliers. Le chef de projet gère l’exécution : planning, ressources, jalons, reporting. Le Business Analyst gère la compréhension : besoins réels, spécifications fonctionnelles, traçabilité des exigences, critères d’acceptance.
Dans les projets sans BA, les spécifications sont souvent rédigées par les équipes IT sur la base de leur compréhension des besoins. Le résultat est un système fonctionnellement correct sur le plan technique mais décalé par rapport aux pratiques métier réelles. Ce décalage n’est visible qu’au moment du déploiement, quand le coût de correction a considérablement augmenté.
4. Une recette fonctionnelle sans critères d’acceptance définis
Dans les projets hospitaliers, la recette est souvent organisée sous forme de sessions de démonstration où les utilisateurs valident visuellement les fonctionnalités. Ce format ne garantit pas que les fonctionnalités correspondent aux besoins réels dans les conditions d’utilisation réelles.
Une recette rigoureuse s’appuie sur des critères d’acceptance définis avant le développement : pour chaque exigence fonctionnelle, un test précis permet de vérifier objectivement si l’exigence est satisfaite. Sans ce référentiel, la recette devient une négociation sur ce que « livré correctement » signifie, au moment le moins favorable pour cette négociation.
5. Une conduite du changement déclenchée après le déploiement
La conduite du changement est presque toujours traitée comme une phase distincte, déclenchée au moment du déploiement sous forme de formations et de communications. À ce stade, il est trop tard pour modifier les fondamentaux du système. La résistance des équipes exprime souvent des problèmes fonctionnels réels que la formation ne peut pas résoudre.
La conduite du changement efficace dans les projets hospitaliers commence dès la phase de cadrage : impliquer les utilisateurs clés dans la définition des besoins, leur présenter des prototypes pour validation, construire les critères d’acceptance avec eux. Quand les utilisateurs ont contribué à définir ce que doit faire le système, leur résistance au déploiement est structurellement moindre.
6. Des dépendances entre systèmes mal cartographiées
Un SI hospitalier est un écosystème complexe : système d’information clinique, gestion des admissions, laboratoire, imagerie, pharmacie, facturation, gestion RH. Ces systèmes communiquent par des interfaces dont certaines sont documentées et d’autres ne le sont pas. Modifier l’un d’eux sans avoir cartographié ses dépendances peut produire des effets de bord dans des systèmes apparemment sans lien.
La cartographie des dépendances est une livraison indispensable de la phase d’audit SI préalable à tout projet de transformation. Elle prend entre une et trois semaines selon la complexité du périmètre. Elle peut éviter des incidents de production dont les conséquences, dans un contexte hospitalier, vont bien au-delà des coûts de correction informatique.
Ce qui distingue les projets hospitaliers qui réussissent
| Facteur | Projets qui dérivent | Projets qui réussissent |
|---|---|---|
| Recueil des besoins | Direction et responsables IT uniquement | Direction + utilisateurs terrain de chaque profil |
| Spécifications | Rédigées par la DSI sans référentiel métier | Rédigées par un BA avec validation métier formelle |
| Contraintes réglementaires | Ajoutées en fin de développement | Intégrées dans les specs fonctionnelles dès le départ |
| Recette | Démonstrations visuelles sans critères définis | Tests sur critères d’acceptance formalisés avant dev |
| Conduite du changement | Formations au moment du déploiement | Implication utilisateurs dès la phase de cadrage |
| Dépendances SI | Gérées au cas par cas en cours de projet | Cartographiées avant le début du développement |
La méthode d’analyse préventive applicable en Suisse romande
Les projets SI hospitaliers qui réussissent partagent une logique de travail commune qui peut être structurée en cinq étapes préventives, applicables à tout projet quelle que soit sa taille.
Étape 1 : l’audit de cadrage
Avant toute décision, un audit de cadrage SI cartographie l’existant, identifie les problèmes réels (pas ceux supposés), et définit le périmètre exact du projet. Cette phase dure entre une et trois semaines selon la complexité du périmètre. Elle produit un rapport de cadrage qui devient la base de tous les arbitrages ultérieurs.
Étape 2 : le recueil structuré des besoins
Les besoins sont recueillis auprès de l’ensemble des profils utilisateurs, pas uniquement des responsables. Des entretiens semi-directifs, des sessions d’observation et des ateliers de co-construction permettent de documenter les pratiques réelles et les besoins non formulés. Cette phase produit une cartographie des cas d’usage qui couvrira tous les scénarios nominaux et alternatifs.
Étape 3 : la rédaction des spécifications fonctionnelles
Le cahier des charges fonctionnel traduit les besoins en exigences vérifiables, avec pour chaque exigence : son identifiant, sa priorité, son critère d’acceptance et sa base réglementaire si applicable. Ce document est le contrat fonctionnel entre l’institution et ses prestataires. Sa qualité conditionne la qualité de tout ce qui vient ensuite.
Étape 4 : la recette structurée
La recette est organisée sur la base des critères d’acceptance définis à l’étape 3. Chaque test est documenté, son résultat tracé, les anomalies priorisées et corrigées avant validation finale. Cette rigueur protège l’institution en cas de litige avec un prestataire et garantit que le système livré correspond aux engagements contractuels.
Étape 5 : le pilotage de l’adoption
Le déploiement s’accompagne d’un dispositif de pilotage de l’adoption : mesure des indicateurs d’utilisation dès les premières semaines, identification rapide des frictions non anticipées, plan de correction priorisé. Cette phase transforme le déploiement d’un événement ponctuel en un processus d’amélioration continue jusqu’à stabilisation de l’adoption.
Checklist préventive pour un projet SI hospitalier
- Les utilisateurs terrain de chaque profil ont été impliqués dans le recueil des besoins
- Les contraintes LPD et réglementaires sont documentées dans les spécifications
- Un Business Analyst a rédigé ou validé les spécifications fonctionnelles
- Chaque exigence fonctionnelle dispose d’un critère d’acceptance vérifiable
- Les dépendances avec les systèmes existants ont été cartographiées
- La qualité des données sources a été évaluée avant la migration
- Des indicateurs d’adoption sont définis et mesurés dès le déploiement
- Un processus de correction post-déploiement est prévu et budgété
Le contexte suisse romand : spécificités à prendre en compte
Les institutions de santé en Suisse romande opèrent dans un contexte réglementaire et organisationnel spécifique qui influe directement sur les projets SI. La nouvelle LPD entrée en vigueur en septembre 2023 renforce les exigences de privacy by design. Les standards d’interopérabilité du Dossier Électronique du Patient (DEP) imposent des contraintes d’architecture précises. La structure hospitalière helvétique, avec ses particularités cantonales, crée des environnements multi-tutelles complexes à gérer dans les projets de transformation.
Ces spécificités ne rendent pas les projets impossibles. Elles rendent l’analyse préalable encore plus indispensable : un projet conduit sans une compréhension précise de ces contraintes produira des spécifications qui devront être partiellement réécrites une fois ces contraintes découvertes.
Questions fréquentes
Quels types de projets SI hospitaliers sont les plus à risque de dérapage ?
Les projets de migration de systèmes legacy (remplacement d’un ancien système par un nouveau), les projets d’intégration de systèmes existants (connexion de systèmes qui ne communiquaient pas), et les projets de déploiement multi-sites (même système sur plusieurs établissements avec des pratiques différentes). Ces trois catégories cumulent les facteurs de risque : dépendances complexes, populations d’utilisateurs hétérogènes et contraintes de continuité de service élevées.
Quelle est la durée typique d’une phase de cadrage pour un projet SI hospitalier ?
Entre deux et six semaines selon la taille du périmètre et le nombre de services impliqués. Ce délai peut sembler long face à la pression d’agir rapidement. En pratique, les institutions qui investissent dans une phase de cadrage rigoureuse récupèrent ce temps dès la phase de développement, grâce à des spécifications plus complètes qui génèrent moins d’allers-retours et moins de correctifs.
Comment convaincre une direction d’investir dans la phase d’analyse préalable ?
Par les chiffres. Le coût de correction d’un problème détecté en phase de cadrage est de l’ordre de quelques jours de travail analytique. Le même problème détecté en phase de développement coûte dix à vingt fois plus. Détecté en production, il peut nécessiter une refonte partielle du système et générer des risques opérationnels dans un environnement où la continuité de service est critique. Présenter ces ratios à une direction permet généralement de justifier l’investissement dans l’analyse préventive.
Un consultant BA externe peut-il être efficace dans un hôpital où il ne connaît pas les processus internes ?
Oui, à condition de disposer d’une expérience sectorielle en milieu hospitalier. Un BA expérimenté dans ce secteur connaît les contraintes réglementaires, les enjeux de continuité de service et les dynamiques multi-parties prenantes spécifiques à la santé. Il ne connaît pas les processus internes de l’institution, et c’est précisément pour cela qu’il conduit une phase de recueil structuré : pour comprendre la réalité spécifique de l’institution avant de rédiger une seule spécification.
Le taux de dérapage est-il le même pour les petites cliniques que pour les grands hôpitaux ?
Les études disponibles portent principalement sur les grandes institutions. Dans les cliniques et hôpitaux de taille moyenne, les projets sont généralement de moindre envergure, mais les causes de dérapage sont les mêmes. La différence est que dans une petite institution, les ressources pour absorber les surcoûts et les retards sont plus limitées : un projet qui dérape dans une clinique de 200 collaborateurs peut avoir des conséquences budgétaires proportionnellement plus graves que dans un hôpital universitaire.
Les méthodes Agile réduisent-elles le risque de dérapage dans les projets hospitaliers ?
Agile réduit le risque de livrer quelque chose de fonctionnellement inadapté, grâce aux itérations courtes et aux validations fréquentes. Elle ne réduit pas automatiquement le risque de problèmes réglementaires ou de résistance au changement si ces dimensions ne sont pas traitées explicitement dans le cadre de travail. Une mise en oeuvre Agile en milieu hospitalier nécessite des adaptations spécifiques pour intégrer les contraintes de conformité et les cycles de validation réglementaire dans le rythme des sprints.
Conclusion
Les projets SI hospitaliers qui dérivent ont en commun d’avoir sous-investi dans l’analyse préalable. Ce sous-investissement se manifeste de façons différentes : besoins recueillis sans les utilisateurs terrain, contraintes réglementaires ignorées dans les spécifications, dépendances entre systèmes non cartographiées. Mais la logique est toujours la même : construire avant de comprendre.
La bonne nouvelle est que les causes de dérapage sont connues, documentées et prévisibles. Elles peuvent être identifiées et traitées avant le début du développement, par une phase d’analyse structurée conduite avec une méthode Business Analysis rigoureuse. Cette phase représente un investissement marginal sur la durée totale d’un projet, et conditionne la réussite de tout ce qui vient ensuite.
Diagnostiquer avant de construire : c’est la règle la plus simple et la plus consistante des projets SI hospitaliers qui réussissent.
Sources et références
Cet article s’appuie sur des données vérifiées :
- Standish Group : CHAOS Report 2020 : taux de succès des projets IT (31% succès, 50% challengés, 19% échecs)
- BCG : Flipping the Odds of Digital Transformation Success, 2020 : deux tiers des grands programmes technologiques manquent leurs objectifs
- Standish Group : CHAOS Report original 1994, republié sur csus.edu : facteurs clés de succès des projets IT
Note de transparence : les données citées portent sur les projets IT en général, tous secteurs confondus. Il n’existe pas à ce jour d’étude publique portant spécifiquement sur les taux de dérive des projets SI hospitaliers en Suisse romande. Les observations sectorielles présentées dans cet article sont issues de l’expérience terrain sur des projets institutionnels conduits en Suisse.
Un projet SI dans votre institution de santé ?
Un premier échange de cadrage permet d’identifier les zones de risque spécifiques à votre projet et de définir le type d’intervention le plus adapté. Sans engagement, en 30 minutes.
Prendre rendez-vous
