Plus on s'empresse à choisir une solution, plus on sert la rentabilité des éditeurs et des intégrateurs, et plus on met en péril la rentabilité du projet.

Dans les projets informatiques, notamment dans le cas de la mise en œuvre d'un ERP, on notera l'empressement des entreprises à choisir la solution. Généralement le scénario est le suivant : la première étape consiste à sélectionner l'éditeur et l'intégrateur; l'analyse des besoins ne vient qu'après, juste avant la réalisation; s'ensuivent alors les tests, le déploiement et la sacro-sainte « gestion du changement ».

Or le verrouillage de la solution intervient à un moment où on connaît encore mal le contexte d'utilisation. Aussi il existe un risque réel que la solution retenue ne corresponde pas aux besoins. C'est par exemple le constat fait par la Cour des Comptes puis par la Commission des Finances de l'Assemblée Nationale dans un rapport sur les systèmes d'information de l'état (voir le rapport parlementaire). Le choix de SAP a été fait pour l'application Chorus (fonctions budgétaires et comptables de l'état) alors qu'il « est difficile de cerner précisément le périmètre du système d'information financière de l'état », indique le rapport. Chorus doit en effet être interfacé avec de nombreuses applications interministérielles.

Le rapport soulève plusieurs points :

1. Le projet était justifié par l'objectif stratégique de « modernisation de la gestion publique » qui supposait la mise en place de contrôle de gestion et de pilotage par la performance au niveau des ministères. Ces systèmes sont propres à chaque ministère et adaptés à chaque contexte. Or le module de comptabilité analytique de SAP impose au contraire une uniformisation des outils analytique pour l'ensemble de l'état.

2. Un autre objectif était la professionnalisation de la gestion immobilière de l'état, impliquant l'établissement d'un compte de résultat par immeuble. Chorus-RE (module de gestion immobilière de Chorus) ne prévois qu'un inventaire du parc des ministères.

3. La gouvernance « technique » mise en place pour coordonner le projet entre les ministères ne permet pas de trancher les questions fonctionnelles qui opposent les ministères.

4. Le projet était justifié en 2006 par les économies réalisées grâce au projet. Or les calculs reposaient sur des « hypothèses fragiles qui n'ont jamais été réexaminées depuis ». Les coûts « constatés et prévus actuellement représentent une certaine dérive ». La recherche d'équilibre budgétaire pourrait se faire en réduisant le nombre de licences et donc le nombre d'utilisateurs et donc l'impact du projet.

5. L'instance de pilotage technique du projet (AIFE) annonçait un démarrage au 1^er janvier 2010 jusqu'à ce que le ministre du Budget reconnaisse « Chorus a pris une année de retard ». Au mieux, ce n'est que 10 ans après le vote de la LOLF de modernisation de l'état que l'on disposera des outils informatiques adéquats.

Cet exemple a été rendu transparent grâce à l'implication de la Commission des Finances de l'Assemblée Générale. Il est significatif de ce que l'on rencontre en entreprise mais que personne n'a intérêt à faire connaître : on s'enorgueillit de ses succès, rarement de ses échecs. Qu'est-ce qui justifie la précipitation à choisir une solution ?  Voir l'illustration proposée par Christophe Midler en 1993 appelée Dynamique de la situation projet.