Le go-live approche, la recette est presque terminée, et l’équipe de l’intégrateur commence déjà à regarder son prochain projet. C’est le moment où une question simple devrait s’imposer au comité de pilotage : si l’intégrateur disparaissait lundi matin, qui saurait paramétrer, corriger et faire évoluer l’ERP ?
Dans la plupart des projets d’ETI, la réponse honnête est « personne en interne ». Le transfert de connaissances est le maillon oublié : il n’a pas de ligne budgétaire propre, pas de jalon contractuel, et il passe après la recette, la reprise de données et la formation des utilisateurs. Ce guide propose une méthode pour le traiter comme un vrai lot de projet : ce qu’il faut transférer, comment le faire sur 12 semaines, comment contractualiser et comment vérifier que le transfert a réellement eu lieu.
Pourquoi le transfert est le maillon oublié
Pendant le projet, l’intégrateur accumule un savoir que personne d’autre ne détient : pourquoi tel écart de paramétrage a été retenu, comment une interface se comporte quand le flux amont est en retard, quelle astuce permet de clôturer le mois sans bloquer la comptabilité. Ce savoir n’est écrit nulle part, parce que le planning ne prévoyait pas de l’écrire.
Le coût apparaît après la mise en production. Chaque demande, même mineure, repart vers l’intégrateur en régie, au taux journalier de ses consultants, avec un délai qui dépend de sa disponibilité et non de votre urgence. La dépendance se transforme alors en rapport de force commercial : renégocier un tarif est difficile quand on ne peut pas se passer de son interlocuteur. Les modalités de ce cadre contractuel sont détaillées dans notre guide du contrat de TMA ; ici, on traite l’amont : réduire ce que vous aurez besoin de lui demander.
Les 4 symptômes d’une dépendance excessive
- Personne en interne ne sait expliquer un paramétrage clé. Lors d’un audit ou d’une question d’un commissaire aux comptes, la réponse est « il faut demander à l’intégrateur ».
- Les anomalies de niveau 1 remontent systématiquement chez lui. Des incidents simples (droit manquant, rejet d’un flux, édition mal filtrée) ne sont pas traités par l’équipe interne.
- Les évolutions sont chiffrées sans contre-expertise. Faute de compétence interne, vous ne pouvez ni challenger l’estimation ni juger si la demande est triviale ou lourde.
- La documentation existe mais personne ne l’a relue. Elle a été livrée en fin de projet, en un bloc, sans validation par ceux qui devront s’en servir.
Si deux de ces symptômes sont présents à quelques semaines du go-live, le risque est réel et il est encore temps d’agir.
Ce qu’il faut transférer : les 5 savoirs
« Transférer les connaissances » reste un vœu pieux tant qu’on n’a pas dit lesquelles. Cinq familles de savoirs couvrent l’essentiel de ce dont une équipe interne a besoin pour tenir l’ERP en autonomie.
- Le paramétrage : organisation, plan comptable, circuits de validation, droits, codes et tables de référence.
- Les interfaces : flux entrants et sortants, fréquences, formats, comportement en cas d’erreur, relances.
- Les données : modèle de données, règles de qualité, procédures de reprise et de correction, gestion des référentiels.
- Les procédures de run : clôtures, traitements batch, sauvegardes, montées de version, gestion des habilitations.
- L’historique des décisions : pourquoi un choix a été fait, quelles alternatives ont été écartées, quels arbitrages métier le justifient.
Le tableau suivant sert de base de pilotage. Chaque ligne doit avoir un responsable nommé côté intégrateur et côté client.
| Savoir | Support de transfert | Responsable (client) | Critère de validation |
|---|---|---|---|
| Paramétrage | Cahier de paramétrage, reverse-demo par processus | Key user du processus | L’interne reproduit un paramétrage dans un environnement de test sans aide |
| Interfaces | Schéma de flux, runbook d’incident par interface | Référent technique | L’interne diagnostique et relance un flux en erreur |
| Données | Dictionnaire de données, procédures de correction | Data owner | L’interne corrige un lot d’anomalies et documente la méthode |
| Procédures de run | Runbooks de clôture et de traitements récurrents | Responsable run | Une clôture complète est exécutée par l’interne, l’intégrateur observe |
| Historique des décisions | Journal des décisions de paramétrage | Chef de projet ERP | Chaque paramètre structurant renvoie à une décision datée et justifiée |
Plan en 5 étapes sur 12 semaines
Le transfert se joue dans les trois mois qui précèdent la clôture du projet, c’est-à-dire autour du go-live et de l’hypercare. Une règle de bonne pratique, à présenter comme une recommandation et non comme une statistique : réserver de l’ordre de 20 % du temps projet à ce transfert, côté intégrateur comme côté équipe interne. Si ce temps n’est pas planifié, il sera absorbé par les urgences.
Étape 1 (semaines 1 à 2) : constituer les binômes nominatifs
Chaque domaine fonctionnel et technique reçoit un binôme : un consultant de l’intégrateur et une personne interne, désignés par leur nom. Pas « l’équipe finance », mais « Claire pour la comptabilité fournisseurs, avec Marc côté intégrateur ». Sans binôme nominatif, la responsabilité du transfert se dilue et personne n’est comptable du résultat.
C’est aussi le moment de vérifier que les profils internes existent. Si le référent technique n’est pas recruté, le transfert n’a pas de destinataire : voir notre analyse des profils et du recrutement d’une équipe ERP pour calibrer l’embauche avant la fin de la période.
Étape 2 (semaines 3 à 5) : shadowing classique
L’interne observe l’intégrateur sur des tâches réelles : traitement d’un incident, ajustement d’un paramètre, clôture de test. Objectif : comprendre la logique, pas mémoriser les clics. L’interne prend des notes qui deviendront la première version des runbooks.
Étape 3 (semaines 5 à 8) : reverse-demo
Les rôles s’inversent. L’interne anime un atelier où il présente à l’intégrateur et aux métiers comment fonctionne un processus : paramétrage, flux de données, points de contrôle. L’intégrateur corrige et complète. Une reverse-demo révèle en une heure ce qu’une relecture de documentation ne montre jamais : les zones où la compréhension est approximative.
Étape 4 (semaines 8 à 10) : runbooks et journal des décisions
Les notes de l’étape 2 et les corrections de l’étape 3 sont consolidées en runbooks (voir section suivante) et dans le journal des décisions de paramétrage. Ce sont les internes qui rédigent, l’intégrateur qui relit, et non l’inverse : un document écrit par celui qui s’en servira est un document utilisable.
Étape 5 (semaines 10 à 12) : test d’autonomie
Le principe est simple : l’intégrateur observe, l’interne exécute. Sur une série de scénarios définis à l’avance (incident d’interface, création d’un nouvel utilisateur avec droits, clôture mensuelle, correction de données, petit changement de paramétrage), l’équipe interne réalise la tâche de bout en bout. L’intégrateur n’intervient que pour constater. Tout scénario non réussi déclenche un complément de formation et une nouvelle tentative avant la validation du jalon.
Ce test doit s’enchaîner avec la phase d’hypercare : les incidents réels des premières semaines de production sont la meilleure matière d’entraînement, à condition que l’interne soit en première ligne et l’intégrateur en soutien.
Documentation utile vs documentation inutile
Les projets ERP produisent des centaines de pages que personne ne lira. Pour le transfert, la bonne documentation se reconnaît à trois critères : elle répond à une question qu’on se posera vraiment, elle est écrite pour être exécutée par quelqu’un qui n’était pas présent, et elle a été testée par un tiers.
Documentation inutile : copies d’écran sans contexte, spécifications fonctionnelles initiales jamais mises à jour, manuels éditeur recopiés, documents livrés en fin de projet sans validation.
Documentation utile : runbooks, schémas de flux à jour, journal des décisions.
Modèle de runbook
Un runbook tient en une à deux pages et suit toujours la même trame :
- Objet : la situation couverte (« Rejet du flux de commandes vers le WMS »).
- Déclencheur : comment on s’en aperçoit (alerte, message d’erreur, appel utilisateur).
- Prérequis : droits nécessaires, accès, personnes à prévenir.
- Étapes de diagnostic : dans l’ordre, avec ce que l’on doit constater à chaque étape.
- Actions de correction : pas à pas, avec les commandes ou écrans concernés.
- Vérification : comment confirmer que le problème est résolu.
- Escalade : quand et vers qui remonter si l’action échoue.
- Dernière validation : date et nom de la personne qui l’a exécuté pour de vrai.
Journal des décisions de paramétrage
Un simple tableau partagé suffit : date, paramètre ou processus concerné, décision prise, alternatives écartées, justification métier, décideur. Il évite que, deux ans plus tard, un nouveau responsable défasse un choix volontaire parce qu’il ressemble à une erreur. C’est aussi la mémoire qui rend la gouvernance possible, notamment dans un centre d’excellence ERP.
Clauses contractuelles à prévoir
Le transfert doit figurer au contrat, sinon il sera sacrifié au planning. Idéalement, ces clauses sont négociées avant la signature ; sinon, via un avenant au moment où le go-live se précise.
- Livrables de transfert listés : runbooks, schémas de flux, journal des décisions, dictionnaire de données, avec un format et un niveau de détail précisés.
- Binômes et temps dédié : engagement de l’intégrateur sur un volume de jours consacrés au transfert, distinct des jours de réalisation.
- Test d’autonomie comme critère de réception : le jalon de transfert est validé uniquement si les scénarios convenus sont réussis par l’équipe interne.
- Jalon de paiement lié : une fraction du solde est conditionnée à la validation du transfert, et non à la seule recette technique.
- Période de garantie : durée et périmètre précisés, avec la règle que les anomalies de paramétrage livré restent à la charge de l’intégrateur.
- Réversibilité : accès aux environnements, aux exports de configuration et aux outils utilisés, y compris après la fin de la mission.
- Non-captivité des personnes : possibilité de recourir à un autre prestataire sans pénalité pour reprendre la maintenance.
Pour la sélection du prestataire dès l’origine, la grille de scoring des intégrateurs ERP permet d’évaluer sa capacité de transfert comme critère à part entière.
Mesurer l’autonomie : 6 indicateurs
Le transfert se mesure. Voici six indicateurs à suivre chaque semaine pendant les trois mois, puis chaque mois pendant la première année.
- Part des tickets traités sans l’intégrateur : le ratio le plus parlant, à suivre par domaine.
- Délai de résolution des tickets internes : il ne doit pas se dégrader quand l’intégrateur se retire.
- Nombre de scénarios du test d’autonomie réussis du premier coup : mesure la qualité réelle du transfert.
- Couverture des runbooks : part des incidents récurrents pour lesquels un runbook validé existe.
- Jours de régie consommés auprès de l’intégrateur : doivent décroître d’un mois sur l’autre.
- Taux de rotation des binômes : si les personnes formées quittent l’équipe, l’autonomie est fragile.
Fixez des cibles avec le comité de pilotage dès le début. Un indicateur sans seuil ne déclenche aucune décision.
Un dernier point sur l’exploitation de ces indicateurs : ne les présentez pas comme un outil de contrôle de l’intégrateur, mais comme un tableau de bord partagé. Un intégrateur qui voit le transfert avancer a intérêt à le faire réussir, car il libère ses consultants et prépare une relation de partenariat plutôt que de dépendance. Revoyez les chiffres en comité de pilotage toutes les deux semaines pendant les 12 semaines, et décidez explicitement, scénario par scénario, de prolonger l’accompagnement ou de lever la présence de l’intégrateur. Cette décision doit être tracée dans le journal des décisions, comme n’importe quel arbitrage structurant.
Pensez enfin au cas où le projet est déjà en production depuis longtemps. Le plan reste valable : il suffit de remplacer la fenêtre « avant la clôture du projet » par une fenêtre de trois mois avant la fin du contrat de régie ou de TMA, et de commencer par le savoir le plus critique, généralement les procédures de clôture et les interfaces.
Erreurs fréquentes et contre-mesures
| Erreur fréquente | Contre-mesure |
|---|---|
| Planifier le transfert après la recette, quand tout le monde est épuisé | Inscrire le lot « transfert » au planning dès le démarrage, avec son budget temps |
| Laisser l’intégrateur écrire toute la documentation | Faire rédiger les runbooks par les internes, relus par l’intégrateur |
| Former des personnes qui n’ont pas le temps | Libérer explicitement une part de leur agenda, validée par leur hiérarchie |
| Attendre le recrutement du référent technique | Lancer l’embauche avant le go-live, ou prévoir un freelance de transition |
| Valider le transfert sur déclaration | Exiger le test d’autonomie, avec l’intégrateur en simple observateur |
| Ne transférer que le « comment » | Tenir le journal des décisions pour conserver le « pourquoi » |
| Payer le solde sans lien avec le transfert | Conditionner une fraction du paiement à la validation du jalon |
Checklist à copier
- Binômes nominatifs désignés pour chacun des 5 savoirs
- Temps dédié au transfert planifié et validé par les managers
- Livrables de transfert listés au contrat ou en avenant
- Runbooks rédigés par les internes, relus et testés
- Journal des décisions de paramétrage tenu à jour
- Reverse-demo réalisée sur chaque processus clé
- Test d’autonomie réussi, l’intégrateur en observateur
- Jalon de paiement lié à la validation du transfert
- Profil technique interne recruté ou identifié
- 6 indicateurs d’autonomie suivis avec cibles fixées
Aller plus loin
Pour cadrer ce qui suit le transfert, lisez notre guide du contrat de TMA et des bonnes pratiques post go-live, la méthode d’hypercare et le guide du centre d’excellence ERP. Pour auditer le niveau d’autonomie de votre équipe avant la fin de projet, vous pouvez aussi prendre contact avec DigitsLane.
