5 questions à poser avant de lancer un projet SI dans votre institution

La plupart des projets SI qui dérivent n’ont pas un problème d’exécution : ils ont un problème de cadrage. Les questions qui auraient dû être posées avant le lancement n’ont pas été posées, et les réponses implicites se révèlent fausses en cours de route. Ce que vous allez découvrir :
  • Les 5 questions qui révèlent si un projet est prêt à démarrer
  • Ce que chaque question permet de détecter en amont
  • Comment utiliser ces questions comme outil de cadrage avec vos équipes

Pourquoi le cadrage est l’étape la plus négligée

La pression à agir rapidement est forte dans les institutions. Un budget est alloué, une direction attend des résultats, des prestataires sont consultés. Dans ce contexte, prendre deux à quatre semaines pour cadrer rigoureusement le projet avant de lancer quoi que ce soit peut sembler contre-productif.

C’est une illusion de coût. Un problème détecté en phase de cadrage se corrige avec une réunion et quelques modifications de spécifications. Le même problème détecté en phase de recette mobilise des semaines de travail supplémentaire et génère des surcoûts significatifs. Détecté en production, il peut nécessiter une refonte partielle du système.

Les cinq questions qui suivent sont celles qu’un audit de cadrage SI pose systématiquement. Elles ne remplacent pas une analyse complète, mais elles permettent d’identifier rapidement si un projet est réellement prêt à démarrer.

Question 01

Quel problème précis ce projet doit-il résoudre ?

Pas « améliorer l’efficacité » ou « moderniser nos outils » : un problème précis, observable, avec des conséquences mesurables actuellement. « Les équipes terrain passent en moyenne 2 heures par jour à ressaisir des données entre deux systèmes non connectés » est un problème précis. « Notre SI est vieillissant » ne l’est pas.

Si les parties prenantes ne s’accordent pas sur une réponse commune à cette question, le projet n’est pas prêt à démarrer. Le lancer quand même conduit à construire des solutions pour des problèmes différents selon les interlocuteurs.

Question 02

Qui sont les utilisateurs réels du système, et ont-ils été consultés ?

La distinction entre commanditaires et utilisateurs réels est cruciale. La direction qui finance le projet et les équipes terrain qui vont l’utiliser au quotidien n’ont pas les mêmes besoins ni les mêmes contraintes. Un système conçu uniquement avec les inputs de la direction sera souvent inadapté aux pratiques réelles du terrain.

Si les futurs utilisateurs opérationnels n’ont pas été impliqués dans la phase de cadrage, c’est le signal le plus fort que le projet va générer de la résistance à la livraison. L’analyse des besoins doit inclure des entretiens avec des représentants de chaque profil utilisateur identifié.

Question 03

Comment saurons-nous que le projet a réussi ?

Définir les indicateurs de succès avant le lancement, pas après. Si vous ne pouvez pas répondre à cette question avec des métriques précises, vous ne saurez pas non plus si le projet a échoué. Et vous ne pourrez pas arbitrer les compromis inévitables qui se présenteront en cours de route.

Les bons indicateurs sont mesurables, attribuables au projet et observables dans un délai défini. « Réduire le temps de saisie de 40% à 6 mois du déploiement » est un bon indicateur. « Améliorer la satisfaction des utilisateurs » ne l’est pas sans protocole de mesure associé.

Question 04

Quelles sont les contraintes non négociables ?

Tout projet SI s’inscrit dans un contexte de contraintes : réglementaires (LPD, FINMA, normes sectorielles), techniques (infrastructure existante, systèmes à intégrer), organisationnelles (ressources disponibles, calendrier fiscal, périodes de gel des changements) et contractuelles (engagements existants avec des prestataires).

Ces contraintes doivent être cartographiées et documentées avant que la première spécification soit rédigée. Ignorer une contrainte réglementaire en cours de projet peut forcer une refonte architecturale coûteuse. En milieu hospitalier et bancaire, cette cartographie est particulièrement critique.

Question 05

Qui décide quand les parties prenantes ne s’accordent pas ?

Tout projet multi-parties prenantes génère des arbitrages. Des exigences contradictoires entre services, des priorités en conflit, des compromis à négocier entre qualité fonctionnelle et respect du planning. Si le circuit de décision n’est pas défini avant le lancement, ces arbitrages seront gérés au cas par cas, souvent de façon incohérente.

La gouvernance du projet, c’est-à-dire qui décide quoi et selon quel processus, doit être formalisée dès la phase de cadrage. Le pilotage de transformation SI inclut systématiquement cette dimension pour éviter les blocages décisionnels en cours de projet.

Comment utiliser ces questions : organisez un atelier de cadrage d’une demi-journée avec les commanditaires du projet et un représentant de chaque service utilisateur. Documentez les réponses. Les points de désaccord ou les réponses vagues identifient exactement les zones de risque à traiter avant de lancer.

Ce que ces questions révèlent collectivement

Posées ensemble, ces cinq questions produisent un diagnostic rapide de la maturité du projet. Un projet capable de répondre clairement aux cinq est prêt à entrer en phase de spécifications. Un projet qui bute sur deux ou trois d’entre elles nécessite une phase de cadrage supplémentaire avant toute autre étape.

Ce n’est pas un retard : c’est une économie. Les semaines investies en cadrage rigoureux se traduisent par des mois gagnés en phase d’exécution et par une qualité fonctionnelle nettement supérieure à la livraison.

Observation terrain : Dans les projets institutionnels conduits en Suisse romande, la question 3 (comment saurons-nous que le projet a réussi ?) est celle qui génère le plus souvent un silence initial dans la salle. C’est systématiquement le premier signal que le cadrage doit être approfondi avant de continuer.

Questions fréquentes

Ces questions s’appliquent-elles à tous les types de projets SI ?

Oui, quelle que soit la taille du projet. Un déploiement de 3 mois et un programme de transformation de 2 ans ont besoin de réponses claires à ces cinq questions. La différence est dans la profondeur de l’analyse associée à chaque réponse, pas dans la pertinence des questions elles-mêmes.

Faut-il un Business Analyst pour animer cet atelier de cadrage ?

Pas nécessairement pour un projet simple. Mais dès que le projet implique plusieurs services, des contraintes réglementaires ou des systèmes à intégrer, un BA apporte une valeur significative : il sait quelles sous-questions poser derrière chaque réponse pour révéler les hypothèses implicites qui, si elles sont fausses, compromettront le projet.

Que faire si les réponses divergent entre les parties prenantes ?

C’est exactement le but de l’exercice. Mieux vaut détecter les divergences lors d’un atelier de cadrage que lors de la recette. Les divergences identifiées en amont deviennent des points d’arbitrage documentés. Celles découvertes en phase de déploiement deviennent des sources de conflit et de surcoût.

Combien de temps prend une phase de cadrage complète ?

De une semaine à un mois selon la complexité du périmètre. Un premier échange de cadrage de 45 minutes permet généralement d’estimer la durée et le niveau d’analyse nécessaire pour votre projet spécifique.

Votre projet SI est-il prêt à démarrer ?

Un premier échange sans engagement permet d’évaluer rapidement la maturité de votre projet et d’identifier les zones de risque à traiter en priorité.

Prendre rendez-vous

Publications similaires