Selon une étude conduite par McKinsey en collaboration avec l’Université d’Oxford sur plus de 5.400 grands projets IT, les projets dépassent en moyenne leur budget de 45 % et leur calendrier de 7 %, tout en délivrant 56 % de valeur en moins que prévu. Ces chiffres traduisent un déséquilibre structurel entre la complexité des projets et la maturité des dispositifs contractuels mis en place pour les piloter.
Les projets de transformation IT concentrent tous les facteurs de risque contractuel : périmètre évolutif, multiples intervenants, dimension internationale, pression sur les délais. Le contrat y est rarement en tête des priorités. Or, les dérives contractuelles ne pénalisent pas seulement le client : elles fragilisent aussi le fournisseur, exposé à des engagements impossibles à tenir ou à des coûts de sortie non anticipés.
Au travers de cet article nourri de retours d’expérience terrain, je vous livre trois dérives récurrentes dans les projets de transformation digitale : ce qui est clarifié en amont n’a pas besoin d’être renégocié dans l’urgence ; chaque sujet traité à froid est un conflit opérationnel qui n’aura pas lieu.
I. Le forfait incomplet : une mécanique défavorable des deux côtés
Lors d’un appel d’offre pour la mise en place d’une nouvelle solution ERP, l’intégrateur en charge de la mise en œuvre de la solution, a remporté le marché sur la base d’un forfait compétitif. Le projet démarre bien. Puis, à mesure que les ateliers avancent et que les équipes métier s’approprient la solution, les zones d’ombre du cahier des charges apparaissent :
- Des besoins mal spécifiés nécessitent des développements complémentaires ;
- Une application utilisée par les équipes achats n’avait pas été répertoriée dans le périmètre initial ;
- La reprise des données historiques s’avère plus complexe que prévu ;
- De nouveaux besoins des équipes finance émergent en testant la solution.
Ces travaux complémentaires doivent être chiffrés et négociés. Le client ne peut souvent pas relancer une mise en concurrence pour ce périmètre supplémentaire et n’a pas toujours de base de référence pour comparer les prix. Il doit donc souvent se résoudre à accepter les conditions proposées, faute d’alternative réelle.
Ce que j’ai constaté : ces avenants arrivent systématiquement à des conditions moins favorables que le contrat initial (tarifs journaliers majorés de 25 à 30 % par rapport aux prix négociés à la signature).
Le chef de projet côté fournisseur peut lui aussi parfois se trouver dans une position délicate : proposer des tarifs élevés dégrade la relation opérationnelle ; proposer des tarifs trop bas sous-dimensionne l’intervention et met à mal d’autres pans du projet. Dans les deux cas, c’est lui qui absorbe les conséquences d’un périmètre insuffisamment cadré en amont.
Ce qu’une gouvernance contractuelle change
Pour éviter ce type de situation, un bordereau d’unités d’œuvre, c’est-à-dire un catalogue de prestations unitaires à prix fixés, doit être mis en place. Ce document existe souvent dans les contrats ; ce qui fait la différence, c’est qu’il soit suffisamment complet pour couvrir l’ensemble des besoins prévisibles : types de développements, profils mobilisables, reprises de données, formations complémentaires.
Un bordereau trop limité déplace simplement la négociation vers les postes qu’il n’a pas anticipés.
Bien construit et négocié en amont, il sécurise les deux parties : tarifs de référence opposables pour le client, arbitrage sans pression commerciale pour le fournisseur.
II. Le contrat rangé dans un tiroir
Passée la signature, le contrat rejoint les archives. Il n’est consulté que le jour où une tension apparaît.
Entre-temps, les choses ont évolué : des fonctionnalités ont été ajoutées ou abandonnées sans avenant, des jalons ont été décalés sans que les conséquences contractuelles soient tirées, et des décisions structurantes ont été prises en réunion, actées dans un compte rendu, sans jamais être formalisées dans le référentiel contractuel.
Ce que j’ai constaté : sur plusieurs projets, douze mois après le démarrage, les évolutions majeures de périmètre n’étaient, dans le meilleur des cas, tracées que par des mails épars. Le contrat existait mais personne ne s’en servait pour piloter.
Le contrat porte pourtant un engagement précis sur les coûts, la qualité et les délais. Dès que les SLA (les engagements de performance fixés contractuellement) ne sont pas suivis, les mécanismes contractuels ne s’activent pas et le rapport de force se déséquilibre.
Sans traçabilité des décisions, le fournisseur s’expose lui aussi à des mises en cause tardives sur des sujets qu’il pensait avoir traités : le défaut de conseil est difficile à activer par le client, mais aussi difficile à écarter sans documentation au fil de l’eau.
Le RACI, un outil souvent sous-exploité
Le RACI (pour Responsable, Approbateur, Consulté, Informé) est une matrice de gouvernance qui associe chaque livrable à un rôle précis : qui réalise, qui valide et décide, qui est consulté, qui est simplement informé.
Sur un projet IT, il permet de répondre à la question que personne ne veut se poser lors d’une crise : « qui avait la responsabilité de cette activité ? » Sans lui, les zones de recouvrement se multiplient et les mises en cause deviennent inévitables des deux côtés.
Ce qu’une gouvernance contractuelle change
Sur un projet bien gouverné, le référentiel contractuel reste vivant et à jour: formalisation des évolutions, suivi des SLA, activation des mécanismes au bon moment.
Ce travail est invisible quand il est bien fait ; ses effets ne se mesurent que lorsqu’il ne se fait pas.
III. La maintenance applicative mal préparée : quand la réversibilité low-cost se paie au prix fort
Une fois la solution mise en production, une équipe dédiée (la TMA, Tierce Maintenance Applicative) prend le relais. Cette équipe peut être celle de l’intégrateur initial ; mais dans de nombreux cas, c’est un prestataire différent, parfois concurrent, retenu à l’issue d’un nouvel appel d’offres.
La clause de réversibilité (les conditions organisant ce transfert) est fréquemment négociée « sans surcoût », incluse dans le forfait comme si elle ne représentait aucune charge réelle.
Ce que j’ai constaté : une réversibilité sans budget est une réversibilité fantôme. Elle existe sur le papier ; elle n’existe pas sur le terrain.
L’équipe de maintenance, insuffisamment formée, ne peut pas assurer seule l’exploitation de la nouvelle solution. Les incidents s’accumulent, les délais de résolution s’allongent, les utilisateurs perdent confiance. Lorsque la TMA est confiée à un concurrent, la situation est encore plus délicate : on est en fin de relation contractuelle avec l’équipe qui connaît le mieux la solution, et le levier de pression du client sur la qualité du transfert est réduit d’autant.
Côté fournisseur, l’équipe projet se retrouve en chevauchement difficile : traiter les incidents (les SLA ne s’arrêtent pas en fin de projet) et transférer la connaissance, alors que ses membres sont déjà attendus sur d’autres missions. L’arbitrage se fait par défaut : les incidents d’abord, visibles immédiatement ; le transfert passe au second plan, et ses lacunes n’apparaissent que plusieurs semaines plus tard.
Ce n’est pas un manque de bonne volonté : c’est la conséquence d’une fin de contrat mal dimensionnée.
Ce qu’une gouvernance contractuelle change
Sur un projet bien structuré, la réversibilité est une stratégie à part entière : planning de transfert phasé avec jalons intermédiaires, modalités opérationnelles décrites dans le contrat de manière détaillée (sur site, à distance, offshore), budget de transition réaliste négocié avant que la question ne devienne urgente.
En conclusion
Ces trois dérives sont la conséquence prévisible d’un dispositif contractuel sous-dimensionné et mal piloté, par rapport à la complexité du projet. Clarifier les sujets en amont et les formaliser tout au long du projet simplifie l’exécution et surtout réduit les conflits par la suite.
Mon retour d’expérience : il est impératif de prévoir une phase de cadrage formelle en début de projet, avec un jalon contractuel de fin de cadrage qui intègre :
- la consolidation du périmètre réel sur la base des premiers ateliers,
- l’utilisation du bordereau d’unités d’œuvre pour chiffrer les compléments déjà identifiés
- la révision du budget du projet, en prenant en compte les éventuels abandons de besoin,
- une réunion de go/no go sur la poursuite du projet sur la base de ce budget révisé.
C’est en effet au tout début du projet les dérives futures se décident et peuvent être réduites ; attendre la conception ou la fin de recette pour arbitrer, est souvent bien trop tard.
Une gouvernance contractuelle structurée ne sert pas à protéger un camp contre l’autre. Elle crée les conditions d’une collaboration maîtrisée, dans l’intérêt des deux parties.
