Diagnostiquer avant de construire : la règle d’or des projets SI réussis
- Pourquoi construire sans diagnostiquer coûte toujours plus cher
- Ce que le diagnostic révèle que les briefs ne montrent pas
- Comment intégrer cette logique dans votre gouvernance de projet
Le biais de l’action immédiate
Quand un problème est visible dans une organisation, la pression naturelle est d’agir vite. Un système lent ? On le remplace. Un processus inefficace ? On l’automatise. Une donnée manquante ? On crée un nouveau champ dans la base.
Cette logique d’action immédiate est compréhensible. Les directions ont des budgets à justifier, des équipes qui attendent des solutions, des échéances à respecter. Prendre du temps pour analyser peut sembler un luxe.
Ce n’en est pas un. C’est une économie. Un problème mal diagnostiqué produit une solution qui résout le symptôme visible sans traiter la cause réelle. Le problème revient sous une autre forme, souvent plus coûteuse à corriger car des couches supplémentaires ont été construites par-dessus.
Règle empirique : Le coût de correction d’un problème de conception est multiplié par 10 à chaque phase franchie. Détecté en cadrage : quelques heures. Détecté en développement : quelques jours. Détecté en recette : quelques semaines. Détecté en production : plusieurs mois.
Ce que le diagnostic révèle
Les processus réels, pas les processus officiels
Toute organisation dispose de processus documentés et de processus réels. Les premiers sont dans les manuels de procédures et les organigrammes. Les seconds sont ce que les équipes font réellement pour que le travail avance, souvent en contournant les processus officiels quand ceux-ci sont inadaptés.
Un système SI conçu sur la base des processus officiels sera adopté difficilement par des équipes qui fonctionnent selon des processus réels différents. La phase de diagnostic, à travers des entretiens terrain et de l’observation directe, révèle cet écart. C’est le fondement de la cartographie AS-IS : documenter ce qui existe réellement, pas ce qui devrait exister selon les procédures.
Les dépendances cachées
Dans les systèmes institutionnels complexes, notamment en milieu hospitalier et bancaire, chaque composant SI est connecté à d’autres par des dépendances que personne n’a formellement documentées. Modifier un système sans avoir cartographié ces dépendances peut produire des effets de bord imprévus sur des systèmes apparemment sans lien.
Un audit de cadrage SI cartographie ces dépendances avant que la première spécification soit rédigée. Cette cartographie, que l’on appelle parfois « analyse d’impact », est l’une des livraisons les plus précieuses d’une phase de diagnostic.
Les besoins non formulés
Les parties prenantes d’un projet formulent des besoins en termes de solutions, pas de problèmes. « Nous avons besoin d’un tableau de bord » est une solution. Le besoin réel pourrait être « nous avons besoin de prendre des décisions d’allocation de ressources plus rapidement ». Ces deux formulations mènent à des systèmes très différents.
Le diagnostic permet de remonter des solutions exprimées vers les besoins réels. Cette transformation de la demande est l’une des compétences centrales du Business Analyst : comprendre ce dont l’organisation a besoin, indépendamment de la solution qu’elle pense nécessiter.
Observation concrète : Dans un projet conduit dans un établissement bancaire genevois, le brief initial demandait un nouveau module de reporting. La phase de diagnostic a révélé que le problème réel était une incohérence dans les règles de calcul des indicateurs entre deux systèmes sources. La solution a été une correction des règles de calcul existantes, sans développement de nouveau module. Coût : quelques jours de travail analytique au lieu de plusieurs semaines de développement.
Diagnostiquer ne signifie pas attendre
Une objection fréquente : « si on passe du temps à diagnostiquer, on perd du temps à livrer ». C’est une fausse opposition.
Un diagnostic bien mené sur un projet de transformation institutionnelle prend entre une et quatre semaines selon la complexité du périmètre. Sur un projet dont la phase de développement durera six à dix-huit mois, c’est un investissement marginal qui conditionne la qualité de tout ce qui vient ensuite.
La question n’est pas « diagnostiquer ou livrer vite ». La question est « livrer quelque chose qui fonctionne ou livrer vite quelque chose qui devra être refait ». La seconde option est toujours plus coûteuse, souvent deux à cinq fois plus sur l’ensemble du cycle de vie du projet.
Comment intégrer cette logique dans votre gouvernance
Intégrer le diagnostic comme étape formelle dans la gouvernance de projet nécessite trois décisions organisationnelles :
- Budgéter le diagnostic séparément du développement. Un budget de cadrage qui doit être justifié a posteriori par les décisions qu’il a permises est plus facilement défendu qu’un poste fondu dans un budget projet global.
- Définir les livrables du diagnostic avant de le commencer : cartographie AS-IS, identification des dépendances, reformulation des besoins, recommandations priorisées. Un diagnostic sans livrables définis tend à s’étirer indéfiniment.
- Conditionner formellement le lancement du développement à la validation du rapport de diagnostic par les parties prenantes clés. Ce point de contrôle crée une gouvernance naturelle qui empêche de passer à la construction avant d’avoir compris le problème.
Point d’attention : Un diagnostic mené uniquement avec la direction sans consultation des équipes terrain produit une carte qui ressemble à l’organisation telle qu’elle devrait fonctionner, pas telle qu’elle fonctionne réellement. Les deux ont une valeur différente pour la conception d’un système SI.
Ce que cette approche change pour les prestataires
Un cahier des charges rédigé après une phase de diagnostic rigoureuse est fondamentalement différent d’un cahier des charges rédigé sans. Il décrit des processus réels, intègre des contraintes vérifiées, et formule des exigences qui correspondent à des besoins réels plutôt qu’à des hypothèses sur ces besoins.
Pour les prestataires techniques, ce type de document réduit considérablement les risques d’interprétation. Leurs estimations sont plus précises, leurs propositions architecturales plus adaptées, et les allers-retours en phase de développement nettement moins fréquents.
C’est ce que les spécifications fonctionnelles issues d’un diagnostic approfondi produisent : un document de référence qui protège toutes les parties sur la durée du projet.
Questions fréquentes
Le diagnostic est-il différent d’un audit ?
Les deux termes sont souvent utilisés de façon interchangeable. Dans la pratique, un audit évalue la conformité à un référentiel existant. Un diagnostic évalue la situation réelle pour en comprendre les causes et les dépendances. Dans le cadre des projets SI, le diagnostic est plus large : il ne vérifie pas seulement ce qui fonctionne ou non, il cherche à comprendre pourquoi et ce que cela implique pour la conception du futur système.
Le diagnostic peut-il être conduit en interne sans consultant externe ?
Oui, dans des organisations qui disposent de profils Business Analyst expérimentés en interne. La difficulté principale d’un diagnostic interne est le biais de confirmation : les équipes internes ont tendance à voir ce qu’elles s’attendent à voir. Un regard externe apporte une capacité à identifier des problèmes que les équipes internes ont cessé de percevoir parce qu’elles y sont habituées.
Combien de temps dure un diagnostic SI ?
De cinq jours à quatre semaines selon la taille du périmètre et le nombre de parties prenantes à rencontrer. Un premier échange de cadrage permet d’estimer précisément la durée et les livrables appropriés pour votre contexte spécifique.
Le diagnostic remet-il en question les décisions déjà prises ?
Il peut le faire, et c’est parfois inconfortable. Un diagnostic qui confirme simplement les décisions déjà prises n’apporte pas de valeur analytique réelle. Sa valeur est précisément dans sa capacité à révéler des hypothèses fausses avant qu’elles soient intégrées dans l’architecture du système.
Faut-il refaire un diagnostic si le projet a déjà commencé ?
Oui, si le projet rencontre des difficultés importantes : résistance des équipes, livrables rejetés en recette, écarts répétés entre estimations et réalité. Un diagnostic en cours de projet est plus limité qu’un diagnostic initial, mais il permet de remettre le projet sur une base analytique solide avant de continuer.
Vous souhaitez diagnostiquer avant de construire ?
C’est précisément le point de départ de chaque mission. Un premier échange permet de définir le périmètre et les livrables d’un diagnostic adapté à votre contexte.
Prendre rendez-vous
