Investir dans l'informatique : les 7 questions à se poser avant de signer

Pourquoi tant de projets déçoivent

Les entreprises disposent presque toutes de logiciels, d'outils et de prestataires. Le problème rare : le manque d'outils. Le problème fréquent : ne plus savoir ce qui fonctionne, ce qui doit évoluer et ce qui peut attendre. Dans ce brouillard, chaque proposition commerciale semble légitime — et chaque « oui » sans cadre devient une dépense qu'on justifie après coup plutôt qu'une décision qu'on prend avant.

Une décision d'investissement peut sembler plus complexe qu'elle n'est. Voici sept questions, dans l'ordre où je les pose. Elles ne prédisent pas l'avenir, mais elles éliminent l'essentiel des faux dossiers.

Les 7 questions

1. Quel problème métier concret cela résout-il ?

La réponse doit se formuler sans le mot « solution ». « Nous perdons deux jours par mois à ressaisir les commandes » est un problème. « Il nous faut un ERP » est une réponse toute faite à une question qu'on ne s'est pas posée. Si le problème ne peut pas être décrit en une phrase comprise par vos équipes terrain, l'investissement n'est pas encore mûr.

2. Que se passe-t-il si nous ne faisons rien maintenant ?

Le statu quo est une option, et elle a un coût — mais souvent moins élevé qu'on ne le craint sous l'effet marketing. Le risque réel (perte de données, blocage d'un service critique, obligation réglementaire) justifie d'agir vite ; la simple angoisse de « prendre du retard » justifie rarement une dépense. Distinguez les deux.

3. Qui va s'en servir au quotidien, et a-t-il été consulté ?

Beaucoup de projets sont décidés entre la direction et un fournisseur, avec les utilisateurs finaux pour exécutants. Le résultat est connu : l'outil est payé, déployé… et contourné. Celui qui fait le travail chaque jour connaît les trois quarts des irritants réels. Cinquante minutes d'entretien avec les premières personnes concernées valent mieux que cinquante pages de spécifications rédigées en chambre.

4. À quoi ressemblera le succès dans douze mois ?

Écrivez deux ou trois indicateurs — pas des impressions : un délai qui raccourcit, une ressaisie qui disparaît, un service joignable. Sans critère de succès formulé avant, on jugera le projet après coup avec les humeurs du moment, et la décision aura été prise deux fois : une fois à l'achat, une fois à l'évaluation.

5. Quel est le coût total — et le coût de sortie ?

Le prix affiché n'est jamais le coût. Ajoutez l'abonnement récurrent, l'exploitation, la formation, les intégrations, l'évolution annuelle. Surtout, demandez : comment récupère-t-on nos données et nos configurations si l'on part un jour ? Un projet dont la sortie est coûteuse ou floue vous lie — ce n'est pas interdit, mais cela doit être un choix explicite, pas une découverte tardive.

6. Qui exploite, qui supporte, qui arbitre ?

Toute décision informatique engage une organisation. Un outil sans personne identifiée pour le maintenir, un incident sans réponse claire à la question « qui appeler ? », une question d'arbitrage sans répondant, et l'investissement deviendra un problème de plus. Nommez ces trois rôles — même s'ils sont partiels ou externes — avant de signer, pas après.

7. Que restera-t-il si le prestataire disparaît ?

On choisit un partenaire pour ses compétences ; on doit aussi se prémunir de sa disparition par les contrats et la documentation : accès, sauvegardes, modes d'emploi, propriété des développements. Une relation saine ne rend pas dépendant. Si l'idée de cette question met mal à l'aise — du côté du fournisseur comme du vôtre —, c'est souvent qu'elle contient une vraie information.

Les trois erreurs classiques

• Décider depuis le catalogue. Choisir la solution avant d'avoir posé le problème : on rationalise un achat plutôt qu'on n'arbitre un besoin.
• Confondre vitesse et précipitation. Un projet urgent mal cadré coûtera deux fois ; un projet important bien cadré commence par une demi-journée d'entretien.
• Tout vouloir décider seul. Le chef d'entreprise qui arbitre tout sans appui finit par arbitrer avec les informations du vendeur. Ce n'est pas un défaut : c'est la conception du système.

La question qui reste

Si vous ne devez en retenir qu'une, gardez la première : quel problème métier concret cela résout-il ? Elle est gratuite, elle est honnête, et elle trie mieux que n'importe quelle matrice. Une bonne décision IT commence rarement par un outil — elle commence par une bonne question.