Pilotage SI • 6 min
Pourquoi un projet SI techniquement fonctionnel peut échouer s’il n’apporte pas de valeur claire aux utilisateurs, et comment remettre les usages métier au centre du cadrage.
Un projet SI échoue rarement à cause de la technique seule.
J’en ai fait l’expérience très concrètement lors du développement d’un outil destiné à un service d’urgences.
Au départ, l’objectif semblait clair : créer un logiciel simple de gestion des flux patients. Visualiser les patients présents, suivre leur localisation, fluidifier l’organisation du service.
Techniquement, la première version fonctionnait. Mais sur le terrain, elle a été un échec.
La première version du projet répondait à l’objectif initial : suivre les flux patients et donner une vision de l’activité en cours.
Mais elle demandait aux soignants de saisir davantage d’informations sur ordinateur, sans leur apporter de bénéfice immédiat dans leur pratique quotidienne.
Résultat : l’outil était perçu comme une charge supplémentaire. Pas comme une aide.
Et un outil non adopté, même techniquement réussi, reste un échec.
La situation a changé lorsque le besoin a été repris avec les utilisateurs eux-mêmes.
La question n’était plus simplement : de quel écran avez-vous besoin ?
Elle devenait : qu’est-ce qui vous fait perdre du temps ? Qu’est-ce qui vous oblige à ressaisir plusieurs fois la même information ? Qu’est-ce qui vous aiderait vraiment pendant la prise en charge ?
À partir de là, le projet n’était plus seulement un logiciel de suivi de flux.
Il devenait un véritable support métier : comptes rendus, prescriptions, données patient, traçabilité, aide à la saisie, automatisations utiles.
La technique n’avait pas changé de rôle. Elle avait simplement été remise au service du bon besoin.
Cette expérience m’a appris une chose essentielle : un projet SI ne réussit pas parce qu’il est déployé. Il réussit parce qu’il est adopté.
Et pour être adopté, il doit apporter une valeur claire à ceux qui l’utilisent vraiment.
La vraie question n’est donc pas seulement : est-ce que le projet fonctionne ? Mais plutôt : est-ce qu’il améliore réellement le travail de ceux qui doivent l’utiliser ?
À mon sens, le rôle d’un DSI, d’un RSI ou d’un chef de projet SI n’est pas seulement de piloter un outil, un budget ou un planning.
C’est de faire le lien entre la stratégie de l’organisation, les contraintes du terrain, la réalité des usages, la sécurité et la capacité technique.
À lire selon votre situation
Ces liens permettent de relier le sujet de l’article à une page plus opérationnelle : offre, cas d’usage, lexique ou prise de contact.
Voir comment Fortalyse peut intervenir lorsqu’un projet SI manque de cadrage ou d’adoption terrain.
Voir les cas d’usage →Clarifier les besoins, prioriser les livrables utiles et sécuriser les arbitrages avec les prestataires.
Voir les offres →Un premier échange permet de voir si le sujet relève d’un recadrage, d’un diagnostic ou d’un accompagnement.
Demander un échange →Parce qu’un outil peut fonctionner techniquement tout en ajoutant de la charge aux utilisateurs, sans bénéfice clair dans leur quotidien. Sans adoption, le projet reste un échec opérationnel.
Il faut repartir des usages réels, identifier les irritants terrain, comprendre les ressaisies inutiles, associer les utilisateurs au cadrage et prioriser les fonctionnalités qui apportent une valeur immédiate.
Son rôle est de faire le lien entre stratégie, contraintes terrain, usages, sécurité et capacité technique, afin que le projet ne soit pas seulement déployé mais réellement utilisé.
Ressources liées
Le rôle d’un RSI n’est pas d’empêcher par principe. Il consiste souvent à dire oui, mais avec un cadre clair, des garde-fous et une responsabilité posée.
Avec le télétravail, une partie du risque a quitté les murs de l’entreprise. Cet article explique pourquoi le réseau domestique ne doit pas être considéré implicitement comme aussi fiable que l’environnement interne de l’entreprise.
Le vrai sujet n’est pas de savoir s’il faut être pro-cloud ou pro-on-prem. Il est de déterminer quel modèle est le plus cohérent pour un service donné, avec une lecture complète des coûts, des contraintes et du niveau de maturité d’exploitation.
Un premier échange permet souvent de reprendre le besoin, de clarifier les irritants terrain, de réaligner les priorités et de remettre le projet au service des usages réels.
