Un projet informatique qui dérape, c’est rarement un problème technique. C’est presque toujours un problème de traduction : entre ce que tu veux, ce que l’intégrateur a compris, et ce que l’outil peut réellement faire.
Ce que ça coûte quand ça part en vrille#
Un projet ERP en PME coûte entre 30 000 et 300 000 euros. Quand ça dérape, le surcoût minimum est de 10 000 euros. Mais le vrai coût n’est pas que financier.
C’est les mois de flottement. Les équipes qui continuent sur l’ancien système pendant que le nouveau se plante. L’énergie perdue à gérer un chantier qui n’avance pas, à courir après des livrables qui n’arrivent jamais.
Selon le Standish Group CHAOS Report, 31% des projets informatiques sont abandonnés avant d’être déployés. Et 70% des projets ERP n’atteignent pas leurs objectifs initiaux.
Ces chiffres ne sont pas là pour faire peur. Ils sont là pour dire que les causes sont presque toujours les mêmes.
Le cas d’un retailer qui allait droit dans le mur#
J’ai été appelé sur une mission chez une boîte retail, plusieurs millions de chiffre d’affaires, une équipe bien en place. Ils avaient lancé une migration ERP depuis quelques mois. Sur le papier, tout était cadré.
Sur le terrain, c’était autre chose.
L’intégrateur n’avançait pas. Les livraisons étaient en retard. Quand le client demandait des comptes, la réponse revenait toujours : “C’est pas possible en standard.” “Il faut du développement spécifique.” “Ça, c’était pas prévu dans le périmètre.”
Le client s’impatientait. Il voyait un outil qui ne ressemblait pas à ce qu’on lui avait montré en démo. Mais sans bagage technique, impossible de challenger l’intégrateur. Il se retrouvait dans la position du non-expert face au prestataire qui parle jargon.
Le diagnostic : une erreur que font presque tous les dirigeants#
Ce qui est logique pour toi n’est pas forcément natif dans le logiciel.
Quand tu décris ton besoin à un intégrateur, tu parles business. “Je veux que mes commerciaux voient les stocks en temps réel.” “Je veux qu’une commande validée génère un bon de livraison automatiquement.” C’est simple. C’est la base. C’est logique.
L’intégrateur note. Il dit oui. Et tu crois que c’est réglé.
Mais dans un ERP, ce qui te semble être “la base” peut ne pas être natif. Ça peut nécessiter un module additionnel, un paramétrage spécifique, ou du développement sur mesure. Et tu l’apprends trois mois plus tard, quand la facture arrive.
Ce n’est pas toujours de la mauvaise foi. L’intégrateur répond à ce qu’il a entendu. Le client formule son besoin en termes business, pas en termes fonctionnels. La traduction s’est mal faite. Et personne n’était là pour la vérifier.
C’est pour ça que choisir un logiciel n’est pas une décision à prendre uniquement sur la base d’une démo.
Ce qu’on a fait pour redresser le tir#
Ma première étape : ne pas prendre parti. Challenger les deux côtés.
Côté client, reprendre le cadrage depuis le début. Pas “je veux un ERP moderne”, mais quels process, quels cas d’usage concrets, quelles contraintes métier. En retail, les besoins autour des prix, des promotions, de la gestion multi-dépôts sont très spécifiques. Est-ce qu’ils avaient été documentés ? Non.
Côté intégrateur, vérifier ce que l’outil pouvait faire nativement, ce qui relevait du paramétrage, et ce qui était vraiment du dev spécifique. Et confronter ça aux besoins réels.
La conclusion était inconfortable : ce n’était pas le bon outil. Et par conséquent, ce n’était pas le bon intégrateur.
Mieux vaut le savoir à 4 mois qu’à 18 mois et 50 000 euros de plus.
Ce que ça t’apprend : le pare-feu humain#
Le problème de fond dans ce cas, c’est l’absence d’un référent côté client.
Pas un DSI. Pas forcément un technicien. Quelqu’un qui parle à la fois business et informatique. Qui peut poser les bonnes questions à l’intégrateur. Qui peut dire “prouve-moi que c’est pas possible” au lieu d’acquiescer. Qui sert de pare-feu entre les promesses du vendeur et la réalité de l’implémentation.
Sans ce profil dans ton équipe, tu subis le projet au lieu de le piloter.
En PME, ce rôle est rarement interne. La boîte n’a pas de compétences IT en house. Ou le profil qui existe n’a pas le recul nécessaire sur ce type de projet.
C’est là qu’un consultant indépendant peut faire une vraie différence. Sans lien avec l’intégrateur, sans intérêt à vendre du dev supplémentaire. Son seul objectif : que le projet aboutisse à ce dont tu as vraiment besoin.
C’est exactement ce que je fais sur les missions d’accompagnement projet informatique.
Les signaux qui montrent que ton projet dérape#
Si tu reconnais un de ces scénarios, ne pas attendre :
- L’intégrateur répond “c’est pas possible” sans proposer d’alternative
- Les délais glissent sans explication claire
- Tu vois un résultat qui ne ressemble pas à ce qu’on t’avait montré en démo
- Les “développements spécifiques” s’accumulent et le budget gonfle
- Tu n’as plus de visibilité sur ce qui est livré et ce qui reste à faire
Un projet qui dérape, ça se sauve. Mais plus tu attends, plus le coût est élevé, financièrement et humainement.
Tu sens que ton projet est en train de partir en vrille ? On en parle 30 minutes, gratuitement. Tu repartiras avec une lecture claire de la situation.
