Un projet qui prend du retard, ça commence toujours pareil. Les premières semaines, tout va bien. Le prestataire est motivé, l'équipe est impliquée, le calendrier tient. Puis à un moment, souvent après la première réunion de suivi, quelque chose grippe. Les validations traînent. Le périmètre s'élargit imperceptiblement. Les réponses aux emails mettent trois jours à arriver. Et quatre mois plus tard, vous regardez un projet censé durer deux mois, qui n'est toujours pas livré. Ce n'est pas une malchance. C'est un scénario que l'on voit se répéter, avec des variantes, dans la quasi-totalité des projets IT qui dérapent en PME.
Ce n'est pas une malchance. C'est un scénario que l'on voit se répéter, avec des variantes, dans la quasi-totalité des projets IT qui dérapent en PME.
Le problème n'est pas technique
Voilà ce qu'il faut comprendre d'emblée : dans la majorité des cas, ce qui fait rater un projet informatique n'a rien à voir avec la technologie choisie. Pas de bug fondamental, pas de mauvais logiciel, pas de prestataire incompétent. Le problème est organisationnel, presque à chaque fois.
Le Standish Group, qui suit les taux de succès des projets IT depuis les années 90, identifie les mêmes causes de dérapage depuis trente ans : périmètre mal défini, absence de sponsor décisionnel, manque de ressources côté client, validations qui bloquent. Rien que des problèmes humains et de gouvernance.
Pour une PME, c'est encore plus vrai. Vos collaborateurs ont plusieurs casquettes. Le directeur administratif qui devait valider les spécifications gère aussi les clôtures comptables. La responsable RH impliquée dans le projet ERP part en congé maternité au milieu du déploiement. Personne ne pilote vraiment, parce que personne n'en a le temps à plein.
Les quatre causes qui reviennent à chaque fois
Le périmètre flou. C'est la cause numéro un. Un projet qui démarre sans liste claire et validée de ce qui est inclus, et surtout de ce qui ne l'est pas, finit toujours par gonfler. Chaque réunion amène son lot de "et si on ajoutait aussi...". Le prestataire dit oui pour préserver la relation. Les délais glissent. Le budget explose. Ce phénomène a même un nom dans le jargon projet : le scope creep. Une étude de ZipDo publiée en 2025 indiquait que 45 % des chefs de projet considèrent cette dérive de périmètre comme leur principal défi, et c'est le résultat d'une seule chose : l'absence de "non" formalisé dès le départ.
L'absence de sponsor interne. Tout projet IT a besoin d'un décideur côté client, quelqu'un qui a l'autorité pour valider les choix, débloquer les ressources et trancher quand les avis divergent. Sans ce sponsor, le projet flotte. Les questions restent sans réponse. Le prestataire prend des décisions à votre place, parfois les bonnes, souvent pas. Et personne ne peut vraiment reprocher quoi que ce soit à qui que ce soit, puisqu'il n'y avait pas de pilote.
Les flux de validation bloqués. Imaginez une PME de 30 personnes qui déploie un nouvel ERP. Pour valider les paramétrages de la comptabilité, il faut le DAF. Pour valider ceux de la logistique, il faut le responsable entrepôt. Pour valider l'interface client, il faut le commercial référent. Ces trois personnes ne sont jamais disponibles en même temps, ne lisent pas les mêmes documents, et ne parlent pas le même langage que le prestataire. Résultat : chaque validation prend deux semaines au lieu de deux jours. Sur un projet de six mois, ça représente des semaines de glissement cumulé.
L'absence de documentation de départ. On aime à croire qu'on se souviendra de ce qui a été décidé en réunion. On a tort. Trois mois après le lancement, personne ne se rappelle exactement ce qui était prévu, ce qui a changé, ni pourquoi. Et quand un désaccord émerge entre vous et le prestataire, sur une fonctionnalité, sur une date, sur un coût, vous n'avez rien à produire pour trancher. La seule base de discussion devient la mémoire de chacun, et elle est toujours différente.
Ce que ça change d'avoir quelqu'un qui pilote
Pour une PME de 45 personnes exerçant dans la distribution, en Suisse romande, qui lance la migration de son ERP historique vers une solution plus moderne. Budget : 90 000 CHF. Durée prévue : huit mois. Un intégrateur reconnu est retenu. Côté client, le directeur général suit le projet en plus de ses responsabilités courantes.
Six mois plus tard, l'ERP n'est pas en production. Le périmètre a évolué trois fois. Deux modules supplémentaires ont été ajoutés sans avenant signé. Le responsable logistique, jamais disponible pour les ateliers de validation, a commencé à contourner le nouveau système en maintenant ses vieux fichiers Excel. L'intégrateur attend des validations depuis cinq semaines. Le budget est dépassé de 30 %.
Ce n'est la faute de personne en particulier. C'est la conséquence directe de l'absence d'un chef de projet dédié.
Un chef de projet (interne ou externe) aurait fait trois choses simples : figer le périmètre par écrit dès le départ avec une procédure de gestion des évolutions, mettre en place un comité de pilotage mensuel avec les bons décideurs, et s'assurer que chaque validation a une date limite et un responsable nominatif.
Ce n'est pas de la haute technologie. C'est de la rigueur organisationnelle. Et c'est précisément ce qui manque.
La réponse n'est pas d'embaucher
La conclusion évidente serait : "il faut recruter un chef de projet IT". Sauf que pour une PME de 30 à 80 personnes, un chef de projet IT à temps plein est rarement justifiable entre les projets. Et les projets, par définition, ne sont pas permanents.
C'est là que le recours à un accompagnement externe prend son sens, non pas comme un luxe de grande entreprise, mais comme un investissement de protection. Pour un projet à 80 000 CHF, consacrer 8 à 12 % du budget à un pilotage structuré externe, c'est souvent la différence entre un projet livré dans les temps et un projet qui dérive de 40 % en coût et en délai.
L'accompagnement LX Project ne remplace pas votre intégrateur. Il s'intercale entre vous et lui, pour que vous ne soyez jamais le seul à ne pas comprendre ce qui se passe, et pour que quelqu'un soit formellement responsable de faire avancer les choses.
Ce qu'on recommande avant de lancer n'importe quel projet IT
Peu importe la nature du projet : déploiement ERP, migration cloud, refonte du SI, déploiement d'un CRM... Quelques réflexes de départ évitent l'essentiel des dérapages.
Commencez par désigner un sponsor interne nommément, avec le pouvoir de valider et de trancher. Rédigez un document de cadrage d'une page, pas un cahier des charges de 80 pages, juste les objectifs, le périmètre, les exclusions, les jalons et les critères d'acceptation. Mettez en place un rythme de pilotage régulier avec compte-rendu écrit à chaque réunion. Et refusez systématiquement toute évolution de périmètre non formalisée par écrit.
Ça ne garantit pas un projet parfait. Mais ça élimine les causes les plus prévisibles d'échec. Et dans la plupart des cas, c'est suffisant pour faire la différence.
Les projets qui réussissent ne sont pas ceux qui n'ont pas eu de problèmes. Ce sont ceux où quelqu'un avait la responsabilité et l'autorité pour les régler.