Projet SI : pourquoi un logiciel techniquement réussi peut devenir un échec métier

Dans beaucoup d’organisations, la réussite d’un projet informatique est encore mesurée principalement à travers des critères de livraison : le logiciel est installé, les comptes utilisateurs sont créés, les données ont été reprises, les formations ont eu lieu, le planning est respecté et le budget reste maîtrisé.

Ces critères sont importants. Ils permettent de vérifier que le projet a été exécuté correctement. Mais ils ne suffisent pas.

Un outil peut respecter le cahier des charges initial et rester inadapté à la réalité du terrain. Il peut répondre aux attentes de pilotage de la direction, tout en ajoutant une charge de travail aux utilisateurs. Il peut produire des tableaux de bord intéressants, mais reposer sur des données que personne ne saisit correctement.

C’est là que l’écart apparaît entre une réussite technique et une réussite métier. La vraie question n’est pas seulement : l’outil fonctionne-t-il ? Elle est aussi : l’outil est-il utile, utilisé et intégré dans le travail réel ?

Lorsqu’un outil n’est pas adopté, on l’explique parfois trop vite par une résistance au changement. Il peut bien sûr exister une part d’habitude, de crainte ou de réticence face à un nouvel outil. Mais dans beaucoup de cas, les utilisateurs ne rejettent pas le changement par principe.

Ils contournent surtout ce qui complique leur travail sans leur apporter de bénéfice clair. Un outil qui ajoute de la saisie sans simplifier une tâche sera vécu comme une charge supplémentaire. Un workflow qui ignore les contraintes terrain sera perçu comme une lourdeur administrative. Un reporting utile à la direction, mais sans valeur immédiate pour les utilisateurs, sera souvent mal renseigné.

Une solution pensée pour un processus théorique risque aussi de se heurter au travail réel. Et lorsque l’outil ne correspond pas au quotidien des équipes, celles-ci trouvent naturellement des solutions alternatives : fichiers personnels, tableaux Excel parallèles, échanges par mail, messages instantanés, notes papier ou procédures informelles.

Le problème n’est alors pas uniquement technique. Il devient organisationnel. L’entreprise se retrouve avec un outil officiel d’un côté, et des usages réels de l’autre.

L’une des difficultés d’un projet SI est que le besoin exprimé au départ n’est pas toujours le besoin réel.

Une direction peut formuler un besoin de suivi, de reporting, de traçabilité ou de pilotage. Ce besoin est légitime. Une entreprise doit pouvoir suivre son activité, sécuriser ses processus, mesurer ses indicateurs et prendre de meilleures décisions.

Mais si ce besoin est traduit directement en fonctionnalités sans comprendre le terrain, le projet peut produire un outil principalement conçu pour ceux qui consultent les données, et non pour ceux qui les alimentent.

Un tableau de bord fiable suppose des données fiables. Des données fiables supposent une saisie simple, logique et intégrée dans le travail quotidien. Une saisie utile suppose que les utilisateurs comprennent l’intérêt de ce qu’ils font.

Si l’outil demande aux équipes de renseigner des informations qui ne leur apportent rien, ou qui arrivent trop tard dans leur processus, la qualité des données sera fragile. À l’inverse, si l’outil aide réellement les utilisateurs à gagner du temps, éviter des erreurs, mieux se coordonner ou retrouver plus facilement une information, l’adoption devient beaucoup plus naturelle.

J’ai vécu cette situation sur un projet applicatif métier. La première intention était pertinente : mieux visualiser un flux, suivre une activité, organiser le service et donner une meilleure visibilité au pilotage.

Techniquement, l’outil fonctionnait. Mais pour les utilisateurs, la première version ajoutait surtout une charge de saisie supplémentaire. Elle répondait au besoin de suivi, mais pas suffisamment aux irritants concrets du terrain.

Les équipes devaient alimenter l’outil, sans percevoir immédiatement ce qu’il leur apportait dans leur propre activité. Le résultat était prévisible : faible adhésion, usage partiel, données incomplètes et donc valeur limitée pour le pilotage.

La vraie bascule est arrivée lorsque le besoin a été retravaillé avec les utilisateurs eux-mêmes. Non pas en leur demandant de concevoir l’outil à la place de l’équipe projet, mais en prenant le temps de comprendre leur réalité opérationnelle.

À partir de ce travail, le projet a changé de nature. L’outil n’était plus seulement un outil de suivi. Il devenait un véritable support métier.

La question n’était plus seulement de produire une information de pilotage pour la direction. Elle devenait : comment aider les utilisateurs dans leur action quotidienne, tout en produisant une donnée utile, fiable et exploitable ?

C’est souvent là que se joue la réussite d’un projet SI. La technique ne disparaît pas. Elle reste essentielle. Mais elle est remise au service du bon besoin, au bon moment, dans le bon contexte d’usage.

Une erreur fréquente consiste à réduire la conduite du changement à la phase de formation. Dans cette logique, on conçoit l’outil, on le paramètre, on le déploie, puis on forme les utilisateurs à la fin.

Mais si les choix structurants ont été faits sans tenir compte des usages réels, la formation arrive trop tard. Elle explique comment utiliser l’outil, mais elle ne corrige pas toujours le fait que l’outil ne répond pas suffisamment au quotidien des équipes.

La conduite du changement doit commencer beaucoup plus tôt. Elle commence dès le cadrage. Elle commence lorsque l’on observe les pratiques existantes, les contournements, les irritants, les ressaisies, les fichiers parallèles, les doubles contrôles et les pertes d’information.

Elle commence lorsque l’on accepte qu’un processus théorique ne corresponde pas toujours au travail réel. Elle commence lorsque l’on cherche la valeur pour les utilisateurs, pas seulement la valeur pour la direction ou le service informatique.

Former les utilisateurs est nécessaire. Mais les associer intelligemment en amont est souvent déterminant.

Associer les utilisateurs ne signifie pas leur demander de dessiner l’application, de choisir l’architecture technique ou de trancher tous les arbitrages fonctionnels. Ce n’est pas leur rôle.

Les utilisateurs connaissent leur métier, leurs contraintes, leurs priorités et leurs irritants. Le rôle du chef de projet, du RSI ou du DSI est de transformer cette connaissance terrain en solution cohérente, sécurisée, maintenable et alignée avec les objectifs de l’entreprise.

Il faut donc éviter deux excès. Le premier consiste à concevoir l’outil sans les utilisateurs, en partant uniquement d’un besoin de pilotage ou d’une vision théorique du processus. Le second consiste à demander aux utilisateurs une liste exhaustive de fonctionnalités, sans arbitrage, ce qui peut conduire à un outil trop complexe, difficile à maintenir et coûteux.

La bonne approche se situe entre les deux : écouter le terrain, comprendre les usages, puis cadrer une solution réaliste. Une solution doit être utile, mais aussi simple. Adaptée, mais pas sur-mesurée à l’excès. Acceptable pour les utilisateurs, mais aussi maîtrisable pour l’entreprise.

Un projet SI ne se limite pas à choisir une solution, suivre un planning ou coordonner un prestataire.

Le rôle du DSI, du RSI ou du chef de projet SI est de faire le lien entre plusieurs dimensions qui peuvent parfois entrer en tension : stratégie de l’entreprise, besoins des métiers, contraintes terrain, sécurité, coûts, faisabilité technique, exploitation future, qualité des données et adoption par les utilisateurs.

C’est précisément ce rôle d’arbitrage qui est essentiel. Une solution peut être séduisante commercialement, mais difficile à maintenir. Elle peut être très complète, mais trop complexe pour les équipes. Elle peut être rapide à déployer, mais mal intégrée au reste du système d’information. Elle peut répondre au besoin immédiat, mais créer de la dette technique.

Le pilotage SI consiste à identifier ces risques avant qu’ils ne deviennent des problèmes opérationnels.

Plusieurs signes doivent alerter après le déploiement d’un outil. Ils ne signifient pas forcément que l’outil est mauvais, mais ils indiquent souvent que l’écart entre le processus prévu et l’usage réel n’a pas été suffisamment traité.

C’est là qu’un regard externe ou une fonction DSI à temps partagé peut aider : reprendre le besoin, objectiver les irritants, identifier les points de blocage, puis arbitrer entre correction fonctionnelle, évolution organisationnelle, formation complémentaire ou simplification du processus.

Dans une PME, un projet SI mal adopté peut avoir un impact important. Le coût n’est pas seulement celui de la licence, de l’intégration ou du prestataire.

Il faut aussi prendre en compte le temps passé par les équipes, les ressaisies, les erreurs, les pertes d’information, la mauvaise qualité des données, les décisions prises sur des indicateurs incomplets, les outils parallèles qui continuent d’exister et la démotivation liée à un outil perçu comme inutile.

Un projet SI mal adopté devient rapidement plus cher que prévu, même si le budget initial a été respecté. À l’inverse, un projet mieux cadré, mieux aligné avec les métiers et mieux piloté produit plus de valeur dans la durée.

Il ne s’agit pas forcément de faire plus complexe. Il s’agit souvent de faire plus juste.

Avant de choisir ou de déployer une solution, il est utile de poser quelques questions simples. Elles permettent de passer d’une logique de déploiement à une logique d’usage.

Un projet SI ne réussit pas quand il est simplement livré. Il réussit lorsqu’il trouve sa place dans l’organisation.

Il réussit lorsqu’il améliore concrètement le travail des équipes. Il réussit lorsque les données produites sont fiables parce qu’elles sont issues d’un usage naturel, et non d’une contrainte artificielle. Il réussit lorsque les métiers, la direction et l’informatique partagent une vision commune de la valeur attendue.

La technologie est importante, mais elle ne suffit pas. La qualité du cadrage, la compréhension des usages, la clarté des arbitrages, la simplicité des processus et l’accompagnement des équipes sont tout aussi déterminants.

C’est particulièrement vrai pour les PME, où les ressources sont limitées, où les équipes cumulent souvent plusieurs rôles, et où un outil mal pensé peut rapidement désorganiser le quotidien.

Avec Fortalyse, je défends une approche pragmatique du système d’information : un SI doit être utile, sécurisé, compréhensible et aligné avec les métiers.

Cela signifie qu’un projet informatique ne doit pas être piloté uniquement sous l’angle technique ou budgétaire. Il doit aussi être regardé sous l’angle de l’usage, de la valeur métier, de la sécurité, de l’exploitation et de l’adoption.

Pour une PME, l’objectif n’est pas de multiplier les outils. L’objectif est de disposer d’un système d’information cohérent, maîtrisé et réellement utile à l’activité.

C’est dans cet esprit que Fortalyse accompagne les dirigeants de PME dans le cadrage, le pilotage et la sécurisation de leurs projets SI.