Dans l’univers des grands projets ERP, on investit des millions dans le logiciel, les experts, la conduite du changement… mais trop souvent, on oublie que le vrai point de bascule se joue bien plus tôt, dans un document que l’on signe parfois à la hâte : le contrat de sous-traitance. Mal rédigé, il ouvre la porte à tous les dérapages. Bien verrouillé, il devient l’allié stratégique du DSI et du Comex.
Le mirage de la promesse logicielle
Les éditeurs et intégrateurs d’ERP ont le sens du marketing. « Accompagnement sur-mesure », « solution robuste », « expertise métier », « délais tenus ». Ces termes séduisent et rassurent. Pourtant, une fois le contrat signé, ce ne sont plus les intentions qui comptent, mais les engagements contractuels concrets. Or, dans de trop nombreux projets, ceux-ci se révèlent flous, insuffisants, ou volontairement ambigus.
Le cas d’un grand groupe industriel ayant confié l’intégration de son ERP Infor LN à un prestataire illustre ce problème. Un contrat de plusieurs centaines de milliers d’euros… sans critères de validation des livrables, sans planification opposable, sans obligation de résultat. Résultat ? Deux ans plus tard, le projet est enlisé, les usines ne peuvent toujours pas migrer, la gouvernance est bancale, et le prestataire… continue de facturer.
Des clauses de moyens, pas de résultats
L’erreur la plus courante : croire qu’un « contrat de prestation de services » protège autant qu’un engagement de livraison. La plupart des contrats ERP se bornent à engager le prestataire à des “obligations de moyens”. Cela signifie qu’il doit faire de son mieux, sans jamais garantir que le projet aboutira.
Dans le cas étudié, aucune pénalité de retard n’était prévue. Le prestataire pouvait multiplier les réunions, corriger des bugs sans fin, livrer des versions instables : tant qu’il montrait qu’il travaillait, il respectait le contrat.
Mais pour le client, chaque mois perdu entraînait des surcoûts humains, une désorganisation opérationnelle, et un effritement de la confiance des équipes terrain. D’où une leçon clé : un contrat déséquilibré tue le projet avant même son démarrage.
Livrables non définis, responsabilités diluées
Un bon contrat doit spécifier qui fait quoi, quand, et selon quels critères de validation. Dans le projet ERP évoqué, aucun livrable détaillé n’était mentionné pour chaque phase : ni recette métier, ni documentation utilisateur, ni maquette validée.
Pire : la responsabilité du prestataire n’était jamais explicitement engagée sur des aspects critiques comme la qualité des données migrées, la performance du système ou l’industrialisation du paramétrage. Tout était traité comme un “effort conjoint”, donc sans responsable clairement désigné en cas d’échec.
Phase de déploiement : le vide juridique
La bascule en déploiement est souvent le moment le plus tendu d’un projet ERP. Les utilisateurs attendent un outil fiable, les directions une mise en production sans incident. Mais que se passe-t-il si l’environnement est instable ? Si les bugs bloquent la facturation ? Si les interfaces ne répondent pas ?
Dans le contrat analysé, la transition vers la TMA (Tierce Maintenance Applicative) n’était pas encadrée par des jalons objectifs. Le prestataire pouvait donc se désengager de certaines corrections en arguant qu’il s’agissait désormais de TMA, même si le socle initial n’avait jamais été validé.
Le résultat ? Un flou complet sur la phase post-projet, avec des allers-retours incessants entre équipes, sans pouvoir opposer un planning ou un état d’avancement formel.
Le contrat, boussole stratégique du DSI
Un bon contrat est plus qu’un document juridique. C’est la colonne vertébrale du projet. Il structure la gouvernance, cadre les responsabilités, permet de piloter les écarts, et surtout, protège l’entreprise en cas de contentieux.
Voici les points essentiels qu’un contrat ERP ne doit jamais négliger :
- Des livrables précis, validés étape par étape, avec des formats et des critères de qualité définis dès le début.
- Un engagement de résultat minimum pour les phases clés : migration, performance, conformité métier.
- Des pénalités de retard, pas pour punir mais pour sécuriser les délais.
- Une gouvernance contractuelle claire : comités de pilotage, arbitrages, validation.
- Une clause de sortie ou de réversibilité, si le prestataire ne remplit pas ses engagements.
- Une gestion de la bascule en TMA, avec des critères objectifs de fin de projet.
Ne plus signer les yeux fermés
Trop d’entreprises continuent de signer des contrats ERP comme s’il s’agissait d’un simple devis. Ce réflexe coûte des millions, des mois de retard, et parfois la carrière de ceux qui ont porté le projet.
Un contrat bien rédigé, c’est un contrat qui prévient les conflits au lieu de devoir les trancher après coup. Il protège l’entreprise, mais aussi le chef de projet, le DSI, le directeur métier impliqué.
Conclusion : la signature ne doit jamais précéder l’exigence
Le projet ERP n’échoue pas à cause du logiciel. Il échoue parce que les règles du jeu ont été mal écrites dès le départ. Dans un monde où chaque ligne de code peut coûter des milliers d’euros et chaque bug bloquer une chaîne de production, le contrat est l’arme stratégique la plus négligée. Il est temps d’en faire un outil de gouvernance à part entière.
En savoir plus sur GDL T&C
Subscribe to get the latest posts sent to your email.