Une entreprise du secteur énergie ouvre son contrat ERP cinq ans après la signature. La clause de réversibilité tient en deux lignes : "Le prestataire s'engage à faciliter la transition." Coût prévu : 0 €. Six mois plus tard, changement d'intégrateur en cours : 12 applications ajoutées depuis 3 ans ne sont documentées nulle part, l'organigramme date de 2 ans avec 40% de turnover, les interfaces systèmes tiers sont partiellement documentées. Le transfert "gratuit" devient un gouffre : 6 mois de chevauchement à 15 j/h par mois, budget multiplié par 3, incidents en cascade.
Ce scénario n'a rien d'exceptionnel. 60% des réversibilités ERP échouent faute de préparation dès le démarrage. Parce qu'une réversibilité "gratuite" sur le papier cache l'absence totale de préparation réelle. Et parce que trop d'organisations pensent que la réversibilité se gère six mois avant la sortie, alors qu'elle doit se construire dès le premier jour du contrat.
Vous pouvez également consulter notre article sur Medium ou notre deck de présentation sur Speakerdeck.
Le piège de la réversibilité "gratuite"
Dans 80% des contrats ERP, la clause de réversibilité ressemble à ceci : "Le Prestataire s'engage à faciliter la transition vers un nouvel intégrateur dans des conditions conformes aux bonnes pratiques du marché." Cette formulation rassure au moment de la signature mais ne produit aucune obligation concrète, aucun livrable défini, aucun budget alloué.
Le jour de la sortie, tout est à construire en urgence. La documentation n'existe pas, le périmètre a dérivé, les personnes clés sont parties sans transmettre leur connaissance. Le budget explose parce qu'il faut rattraper en quelques mois ce qui aurait dû être maintenu pendant cinq ans..
La réversibilité commence à J+0, pas au bout de 3 mois
Un plan de réversibilité n'est pas un document figé mais un système vivant qui accompagne le projet. Les trois erreurs classiques : se dire "on verra plus tard" (le périmètre a déjà dérivé), croire que "le prestataire maintient sa doc à jour" (sans obligation contractuelle, jamais maintenue), et penser qu'"avoir une clause suffit" (une clause vague ne vaut rien).
Ce qu'il faut mettre en place dans les trois premiers mois
Dès le démarrage du contrat, trois actions fondamentales doivent être engagées :
- définir le plan de réversibilité initial avec le périmètre applicatif couvert, l'architecture technique documentée, l'organigramme des acteurs et la cartographie des interfaces.
- contractualiser les obligations de mise à jour : à quelle fréquence ce plan sera-t-il actualisé, dans quel format, avec quel niveau de validation par le client. Cette structuration de la gouvernance prend environ cinq jours supplémentaires.
- intégrer la réversibilité dans la gouvernance projet en prévoyant un point dédié lors des comités mensuels et une revue approfondie semestrielle.
Au total, l'investissement initial atteint environ vingt jours de travail, soit 15 000 à 20 000 euros pour un projet de 1 à 2 M€. L'ordre de grandeur est de quelques pourcents.
Le périmètre glisse toujours : anticipez-le
Un exemple de contrat type : le contrat initial porte sur 8 modules SAP. Cinq ans plus tard, le périmètre réel a bien évolué :
- 8 modules SAP historiques
- 4 nouvelles applications SaaS connectées pour répondre aux besoins du métier
- 3 interfaces systèmes tiers qui n'avaient pas été demandées initialement
- Une refonte complète module comptabilité qui a été migré dans une nouvelle version
- Tout le reporting a été basculé dans Power BI
Résultat : périmètre +40% plus large que documenté.
Pour éviter cela, la clause contractuelle doit être sans ambiguïté : toute évolution du périmètre applicatif doit être intégrée au plan de réversibilité sous 30 jours maximum. Avec un audit semestriel de conformité avec validation client. Pénalités : 1% du montant annuel par élément manquant.
Maintenir l'organisation à jour
Sur 5 ans, le turnover atteint 30-50%. L'obligation contractuelle doit porter sur l'organisationnel : mise à jour trimestrielle de l'organigramme, identification des personnes clés (< 3 mois d'ancienneté = risque), documentation formalisée de chaque départ d'acteur clé.
Transfert de connaissances versus montée en compétences : la distinction qui sauve les budgets
C'est l'un des malentendus les plus coûteux dans les réversibilités sur les projets ERP, EAM ou les programmes de transformation digitaux, qu'ils soient simples ou complexes. À la sortie, tout le monde pense que le sortant va "former" l'entrant sur la solution. Résultat : des semaines perdues, des tensions entre les parties, un budget qui explose.
Le transfert de connaissances n'est pas une montée en compétences. Cette distinction,est fondamentale pour éviter les dérives.
Ce que le prestataire SORTANT doit transférer
Le transfert de connaissances couvre exclusivement le contexte client et les spécificités du projet :
- Contexte client : organisation interne, processus métier spécifiques, culture d'entreprise, interlocuteurs clés et leur rôle réel (pas seulement leur titre)
- Particularités du projet : customisations réalisées, interfaces développées, historique des décisions techniques (pourquoi tel choix plutôt qu'un autre), dette technique accumulée
- Irritants récurrents : problèmes connus et leurs solutions de contournement, points de vigilance saisonniers, pièges à éviter
- Connaissance métier : cycles de clôture comptable, périodes critiques (facturation, arrêtés), contacts clés chez les partenaires
Dans le secteur de l'énergie par exemple, le transfert couvre des notions complexes : cycles de facturation versus tarifs régulés, gestion des certificats d'économie d'énergie, périodes critiques liées aux augmentations tarifaires réglementaires.
Ce que le prestataire ENTRANT doit maîtriser AVANT le démarrage
La montée en compétences reste à la charge exclusive du prestataire entrant et ne fait pas partie du transfert :
- Fondamentaux techniques de l'ERP (SAP, Oracle, IFS, etc.)
- Paramétrages standards de l'ERP
- Formation technique sur l'outil
- Compétences de base attendues pour le niveau de service contractualisé
La clause contractuelle doit être explicite : le transfert porte exclusivement sur la connaissance du contexte client et des spécificités projet. Le nouvel entrant certifie disposer des compétences techniques avant le démarrage. Toute formation technique complémentaire est à sa charge et ne peut justifier ni surcoût ni retard.
Cette distinction rejoint l'évolution du rapport de force entre phases contractuelles, tel que détaillé dans l'article Protéger la marge en période de crise. Pendant l'appel d'offres, le client peut exiger que l'entrant démontre ses compétences techniques. Une fois le contrat signé, ce levier disparaît — d'où l'importance de verrouiller cette exigence dès la consultation.
Propriété du code : sécuriser les droits dès la signature
Règle absolue : tout code développé spécifiquement pour le client appartient au client, pas au prestataire. C'est pourtant une source récurrente de conflits au moment de la réversibilité.
La clause de propriété intellectuelle doit être explicite dès la signature : l'ensemble des développements spécifiques (scripts, interfaces, paramétrages, customisations) sont la propriété exclusive du client. Le prestataire s'interdit toute réutilisation sans accord écrit. Les codes sources sont remis au format exploitable : non compilé, commenté, versionné, avec documentation technique.
Une bonne pratique : le client doit avoir un accès en lecture seule au code source pendant toute la vie du contrat. Pour les projets critiques, un dépôt du code chez un tiers de confiance (comme l'Agence de Protection des Programmes) est parfois mis en place, même s'il n'est pas forcément nécessaire pour être juridiquement protégé?
Les trois phases d'un transfert réussi : une approche progressive et contractualisée
Un transfert de réversibilité ne peut pas se faire en une fois. Comme le soulignent Alain Brunet et Franck César dans leur ouvrage de référence Contract Management (Eyrolles, 2029), l'incomplétude contractuelle est une réalité structurelle qu'il faut gérer activement. Cette incomplétude s'applique particulièrement au transfert de connaissances : on ne peut pas tout documenter, tout transférer d'un coup. La connaissance se construit progressivement, par l'observation, puis la pratique supervisée, puis l'autonomie.
Pour un périmètre critique avec un transfert d'environ 3 mois, voici les trois phases à contractualiser :
Phase 1 : Observation (2-4 semaines, soit 15-25% du transfert)
Le responsable contractuel est le prestataire sortant. Pendant cette phase, l'entrant découvre, observe et cartographie l'environnement. Il participe aux comités de pilotage en mode auditeur, sans responsabilité opérationnelle. Il lit la documentation existante et identifie les zones grises. Le sortant reste pleinement responsable de la production et répond à toutes les questions de l'entrant.
Cette phase est cruciale car elle permet à l'entrant de comprendre ce qui n'est pas écrit : les relations informelles, les points de friction récurrents, les raccourcis pris au fil des années. Brunet et César parlent de "connaissance tacite" — celle qui ne figure dans aucun document mais qui fait la différence entre un projet qui fonctionne et un projet en difficulté.
Phase 2 : Responsabilité partagée (6-10 semaines, soit 50-60% du transfert)
Le responsable contractuel reste le prestataire sortant. L'entrant prend progressivement la main sur les activités. Il agit sous supervision du sortant qui reste garant des résultats, corrige les erreurs et valide les livrables. C'est la phase la plus intense en termes de charge de travail car les deux équipes travaillent en parallèle.
Le sortant doit accepter de "lâcher prise" progressivement, ce qui n'est pas toujours naturel — surtout s'il reste convaincu que "lui seul sait faire". Le client doit arbitrer fermement pour éviter que cette phase ne s'éternise.
Phase 3 : Autonomie avec support (3-6 semaines, soit 20-30% du transfert)
Le responsable contractuel devient le prestataire entrant. L'entrant est désormais responsable de la production. Le sortant passe en mode hotline avec une disponibilité dégressive : 5 jours par semaine au démarrage, puis 3 jours, puis 1 jour avant la clôture définitive. Cette dégressivité doit être contractualisée pour éviter les dérives.
Règle critique : le passage d'une phase à l'autre doit être conditionné à la validation formelle du client avec une grille d'évaluation objective (voir paragraphe Indicateurs de pilotage en fin d'article). Si le retard est imputable au sortant : pénalités contractuelles. Si le retard est imputable à l'entrant : prolongation de la garantie sortant sans surcoût pour le client.
Les 6 erreurs qui tuent une réversibilité
Après près de 20 ans dans le pilotage de projets ERP, voici les six erreurs récurrentes que j'ai souvent constatées:
- ❌ Reporter le plan de réversibilité "pour plus tard"
Chaque mois sans documentation à jour creuse un écart impossible à combler. AU bout de 6 mois, il est déjà trop tard. - ❌ Confondre transfert de connaissances et formation technique
Budget qui explose, tensions entre parties. Le sortant transmet le contexte client, pas les fondamentaux de mise en place d'un ERP et son maintien en Conditions Opérationnelles. - ❌ Négliger la propriété du code
Blocage juridique à la sortie : 6 mois de médiation pendant que le projet est gelé car le sortant "voudrait rester" et utilise son seul levier. - ❌ Oublier de maintenir la documentation à jour
Sans obligation contractuelle assortie d'un contrôle régulier, la documentation n'est jamais maintenue. La reconstitution est coûteuse car elle nécessite de faire appel à des architectes experts pour tout rétrodocumenter - ❌ Ne pas intégrer les nouvelles applications au plan
La dette de documentation qui s'accumule. À la sortie : découverte d'un périmètre qui a doublé. Ce périmètre figure t -il au moins au périmètre de l'appel d'offres qui a sélectionné le nouvel entrant ? - ❌ Absence de grille d'évaluation objective des 3 phases
Décisions au ressenti, pas sur des faits mesurables. Le sortant veut partir vite, l'entrant n'ose pas dire qu'il n'est pas prêt.
L'erreur originelle : accepter une clause "gratuite" sans obligations précises. Une clause vague, sans livrables définis, sans calendrier, sans pénalités = aucune préparation réelle.
Côté fournisseur : sécuriser la sortie sans détruire la marge
L'article Protéger sa marge en période de crise montre que le Contract Management n'est plus une posture juridique mais une posture économique. Cette vision s'applique pleinement à la réversibilité, qui doit être pensée des deux côtés de la relation.
Ne pas offrir une réversibilité "gratuite" qui sera facturée ailleurs
Trop de fournisseurs acceptent d'inclure la réversibilité "gratuitement" dans leur offre initiale pour remporter le marché. Cette gratuité apparente cache deux risques : soit le transfert sera bâclé faute de budget alloué, soit les coûts seront reportés ailleurs (sur la TMA, sur les évolutions, sur le support). Dans les deux cas, la relation se dégrade à la sortie.
La bonne pratique consiste à budgétiser explicitement le transfert dès le départ : une enveloppe de 20 à 40 jours selon la complexité, clairement identifiée dans le contrat. Cette transparence protège les deux parties.
Protéger la propriété intellectuelle des développements génériques
La clause de propriété intellectuelle (voir section existante de l'article) doit distinguer deux catégories de code :
- Le code spécifique client : appartient au client, doit être remis intégralement
- Les composants génériques développés par le prestataire : peuvent faire l'objet d'une licence d'utilisation plutôt que d'une cession de propriété
Cette distinction, conforme aux pratiques de l'Agence de Protection des Programmes, évite les blocages juridiques à la sortie tout en préservant les intérêts légitimes du fournisseur.
Anticiper les claims légitimes en cas de défaut de coopération client
Comme le soulignent Brunet et César, un claim est un "instrument contractuel d'ajustement", pas une déclaration de guerre. Si le client n'a pas maintenu la documentation à jour pendant 5 ans (malgré l'obligation contractuelle), le fournisseur peut légitimement facturer le temps de reconstitution. Le claim doit être documenté en temps réel, reposer sur des clauses activables du contrat et chiffrer précisément l'impact.
Comprendre la psychologie de fin de contrat
Brunet et César décrivent trois phases comportementales dans la vie d'un contrat : la phase "norme" (début, respect des règles), la phase "gain" (exécution, recherche de performance) et la phase "aversion aux pertes" (fin, chacun cherche à minimiser ses pertes plutôt qu'à optimiser les gains).
En fin de contrat, les deux parties sont en aversion aux pertes. Le sortant veut partir vite avec le minimum d'effort. L'entrant n'ose pas dire qu'il n'est pas prêt par peur de perdre le marché. Le client hésite à prolonger par peur des coûts. Cette compréhension psychologique aide à structurer une sortie plus sereine : des jalons de validation objectifs, des pénalités symétriques, une gouvernance renforcée.
Indicateurs de pilotage : votre tableau de bord réversibilité
Indicateurs proposés
Un plan de réversibilité sans indicateurs de suivi n'est qu'un document de plus dans un SharePoint oublié. Les bonnes pratiques de l'AFCM (Association Française du Contract Management) recommandent de définir des KPIs mesurables dès le démarrage du contrat.
La grille d'évaluation des phases de transfert :
Pour objectiver le passage d'une phase à l'autre (voir Amélioration 1), une grille de validation formelle est indispensable :
Pour passer de la Phase 1 (Observation) à la Phase 2 (Responsabilité partagée), l'entrant doit démontrer sa connaissance de l'architecture technique, des processus métier critiques et des interlocuteurs clés. Évaluation par QCM et entretien avec le client.
Pour passer de la Phase 2 à la Phase 3 (Autonomie), l'entrant doit avoir traité au moins 10 incidents en supervision sans erreur majeure et réalisé une livraison complète validée par le client.
Pour clôturer la Phase 3, le taux d'incidents résolus en autonomie doit dépasser 95%, et le client doit valider formellement la fin du transfert.
Sans ces indicateurs objectifs, les décisions se prennent "au ressenti" — et le sortant part trop vite pendant que l'entrant n'ose pas avouer qu'il n'est pas prêt.
Votre assurance-vie contractuelle se paie dès la signature
La réversibilité n'est pas un document figé mais un système vivant qui se construit le premier jour et se maintient jusqu'au dernier. Pour Abrennis, accompagner nos clients sur la structuration contractuelle de la réversibilité dès l'amont est l'un des leviers les plus efficaces pour éviter les contentieux coûteux et sécuriser les transitions.
Une clause de réversibilité bien pensée ne coûte que 2 ou 3% du budget du projet. Mais une réversibilité improvisée peut mettre en péril un projet entier, dégrader durablement la relation avec les équipes métier, et transformer une simple transition en une crise de plusieurs mois. L'équation est simple : investir maintenant pour être serein demain, ou improviser demain et payer le prix fort.
📋 Envie d'aller plus loin ? Découvrez comment structurer vos contrats dès l'amont ou consultez notre guide complet du Contract Management.
Parcourez nos ressources par niveau d'expertise
Que vous découvriez le Contract Management ou que vous cherchiez une expertise pointue sur un projet spécifique, nos articles sont organisés en 4 niveaux pour vous guider efficacement.
📘 Niveau 1 : Découvrir les fondamentaux
Vous débutez ou souhaitez une vision synthétique ? Commencez ici.
→ Introduction au Contract Management : Vue d'ensemble et enjeux
📗 Niveau 2 : Approfondir les concepts
Vous voulez comprendre comment ça marche concrètement ? Plongez dans ces articles.
→ Contract Management : mode d'emploi : Définition, outils, méthodes et formation
→ Cycle de vie du Contrat : Les 6 étapes clés du cadrage à la clôture
→ Aligner Contract Management et enjeux métier : Comment cadrer avec les métiers (et pas à côté d'eux)
→ Contractualisation: impacts d'un échec et leviers de succès : 6 risques à éviter, 6 leviers à activer
→ Protéger sa marge en période de crise : Vision double client/fournisseur pour sécuriser vos marges et vos coûts
📕 Niveau 3 : Expertise métier
Vous pilotez un projet spécifique ? Ces guides sectoriels et métier vous donnent les clés.
- Projets ERP et transformation digitale : → Guide complet : Réussir son appel d'offres ERP : Méthodologie en 2 temps (éditeur puis intégrateur), contractualisation, pièges à éviter
- Maintenance et gestion d'actifs : → Guide EAM : Choisir sa solution de gestion d'actifs : Best of Breed vs solutions intégrées, maintenance prédictive, ROI
- Secteur de l'énergie : → Enjeux des projets de transformation digitale dans l'énergie : Spécificités réglementaires (CRE, TURPE), marchés publics, souveraineté des données
📙 Niveau 4 : Outils & Ressources
Besoin d'une définition, d'un modèle ou d'un outil ? Consultez nos ressources.
→ Glossaire du Contract Management : 75 définitions essentielles (marchés publics, Agile, juridique, finance)
→ FAQ Contract Management : Réponses aux questions fréquentes
→ Contrats FIDIC Volume 1 : Présentation des books FIDIC et des 5 Golden Principles
→ Contrats FIDIC Volume 2 : FIDIC Silver Book — Piloter un projet biomasse EPC
→ Contrats FIDIC Volume 3 : FIDIC Red Book — Piloter un projet de construction de barrage
→ Contrats FIDIC Volume 4 : FIDIC Yellow Book Book — Piloter un projet de construction de station d'épuration
Besoin d'accompagnement sur votre prochain contrat ?
Vous lancez un appel d'offres ERP, renouvelez un contrat de TMA ou pilotez un projet complexe nécessitant un cadrage contractuel solide ?
Abrennis vous accompagne dans :
- La rédaction de CCTP et DCE alignés sur vos enjeux métiers
- La mise en place d'outils de pilotage contractuel (tableaux de bord, revues, indicateurs)
- L'audit de contrats existants et l'identification de leviers d'amélioration
- La formation de vos équipes au Contract Management opérationnel
👉 Contactez-nous pour un premier échange sans engagement, ou consultez nos références terrain pour découvrir nos accompagnements concrets.
À propos de l'auteur
Alain Boyenval est le fondateur du cabinet Abrennis, spécialisé en Contract Management et pilotage de projets ERP pour le secteur de l'énergie.
Fort de 20 ans d'expérience auprès des grands opérateurs français — RTE, EDF, Enedis, GRDF — il a piloté des projets de transformation digitale représentant plusieurs dizaines de millions d'euros : déploiements SAP IS-U, mise en place de centres de services, structuration d'appels d'offres en marchés publics.
Son passage chez Arcwide (joint-venture BearingPoint/IFS) lui a permis d'accompagner les nouveaux acteurs de l'énergie : producteurs photovoltaïques, opérateurs de bornes de recharge, producteurs de biométhane.
Expertise clé : Contract Management, SAP IS-U, IFS Cloud, Maximo, TMA, appels d'offres ERP, secteur énergie.
Mis à jour le 14 janvier 2026