Pourquoi 1 projet SI sur 2 dépasse son budget : ce que 20 ans de terrain m’ont appris

Un projet SI peut être techniquement irréprochable, confié à une équipe compétente, doté d’un budget réaliste — et dériver quand même. Après vingt ans d’interventions en transformation digitale dans des institutions suisses, j’ai observé les mêmes mécanismes de dérapage se reproduire, indépendamment du secteur, de la taille de l’organisation ou des outils choisis.

La cause profonde n’est presque jamais technique. Elle est fonctionnelle, organisationnelle, humaine. Et elle est détectable tôt — à condition de savoir où regarder.

1. On parle de solutions avant d’avoir compris le problème

C’est la dérive la plus fréquente et la plus coûteuse. Dès le premier atelier de cadrage, la conversation porte sur les outils, les plateformes, les architectures techniques. La question « de quoi avez-vous réellement besoin ? » passe après la question « quelle technologie allons-nous utiliser ? »

Sur un projet de refonte SI dans un établissement hospitalier de plus de 10 000 collaborateurs, la première demande de l’équipe dirigeante portait sur le choix de la plateforme. Avant de répondre à cette question, j’ai insisté pour cartographier les processus métier existants. Ce qu’on a trouvé : trois services utilisaient le même type de document avec trois nomenclatures différentes. Personne ne le savait. Personne ne se l’était demandé.

Si on avait construit le SI sur cette base, on aurait livré un outil techniquement fonctionnel que personne n’aurait utilisé de la même façon. La dérive n’aurait pas été visible immédiatement — elle se serait manifestée 6 mois après le déploiement, sous forme de tickets de support, de formations répétées, d’adoption partielle.

2. Le cahier des charges décrit ce que l’IT a compris — pas ce que le métier veut

Un cahier des charges mal rédigé ne ressemble pas à un document incomplet. Il ressemble à un document complet et cohérent — mais qui décrit la réalité vue par un seul acteur plutôt que la réalité partagée.

Le fossé MOA/MOE — entre la maîtrise d’ouvrage qui exprime les besoins et la maîtrise d’oeuvre qui les réalise — est structurellement présent dans tout projet SI. Il ne disparaît pas parce qu’on a organisé des ateliers. Il disparaît seulement quand les deux parties ont validé les spécifications dans un langage commun, avec des critères d’acceptation testables.

Sur un projet de refonte applicative dans le secteur financier genevois gérant plusieurs dizaines de milliards CHF d’actifs, le premier draft du cahier des charges était techniquement correct. Deux semaines d’ateliers de validation avec les équipes métier ont révélé que 40% des spécifications décrivaient ce que l’équipe IT avait compris des besoins — pas ce que le métier voulait réellement. Ces corrections ont eu lieu avant le début du développement. Le coût : 2 semaines supplémentaires de cadrage. L’alternative : plusieurs mois de reprises après livraison.

3. La conduite du changement est traitée comme une ligne dans le planning

Dans la majorité des projets SI que j’ai observés, la conduite du changement apparaît dans le planning sous forme d’un bloc de quelques semaines, positionné juste avant le déploiement. Elle est conçue comme une phase — alors qu’elle est un projet dans le projet.

Les utilisateurs ne résistent pas au changement par principe. Ils résistent parce que le nouveau système perturbe des habitudes construites sur des années, parce qu’ils n’ont pas été associés à sa conception, et parce que les formations arrivent trop tard et trop vite.

Sur un projet de déploiement SI dans une institution sociale cantonale de 1 300 collaborateurs répartis sur 50 sites, la résistance n’était pas idéologique. Elle était pratique : les équipes terrain ne pouvaient pas bloquer deux heures pour une formation en salle classique. La solution n’était pas de simplifier la formation — c’était de la réinventer : référents par site formés en priorité, documentation contextuelle accessible directement depuis l’outil, sessions de 20 minutes intégrées dans les réunions existantes. Le taux d’adoption à 6 mois a dépassé les projections initiales.

4. La recette fonctionnelle est la première victime des retards

Quand un projet prend du retard — et il prend presque toujours du retard — la première phase comprimée est la recette. La pression du planning, la fatigue des équipes, l’impatience des directions : tout pousse à raccourcir ou à bâcler cette étape.

C’est une erreur dont le coût est systématiquement sous-estimé. 80% des anomalies signalées en production dans les 30 jours suivant un déploiement sont détectables en recette — à condition que le plan de recette soit complet et que les cas d’usage réels aient été testés, pas seulement les cas nominaux.

La recette n’est pas une formalité de fin de projet. C’est la dernière opportunité de détecter ce qui ne fonctionnera pas avant que vos utilisateurs le découvrent à votre place.

5. L’absence de gouvernance de projet visible

Un projet SI sans gouvernance claire dérive silencieusement. Les décisions s’accumulent sans être formalisées, les changements de périmètre s’ajoutent sans être évalués, les alertes remontent sans trouver de point de décision.

La gouvernance d’un projet SI ne se résume pas à un comité de pilotage mensuel. Elle comprend des points de décision définis en amont, un processus de gestion des évolutions de périmètre, des indicateurs de progression mesurables, et un circuit d’escalade fonctionnel.

Le tableau des dérives les plus fréquentes

Checklist de démarrage — les 10 points à vérifier dans les 30 premiers jours

France Le Guern

Business Analyst Senior — Transformation SI & Data | Infinity Aurora | Genève