Un lundi matin, la direction informatique apprend que l’administrateur ERP a démissionné, ou que le DSI qui avait conduit le projet quitte l’entreprise. Le préavis est de trois mois, parfois d’une semaine. Personne d’autre ne sait vraiment comment l’ERP est paramétré, quelles interfaces tournent la nuit ni où sont rangés les mots de passe des comptes techniques.
C’est le risque clé-homme appliqué à l’ERP. Il touche surtout les ETI, où un ou deux profils concentrent des années de décisions jamais écrites. Ce guide s’adresse au DG, au DAF et au nouveau DSI qui hérite de la situation : un plan de reprise en quatre semaines, avec des livrables concrets à chaque étape. Il traite le départ d’une personne interne. Si votre dépendance porte sur le prestataire, lisez plutôt notre guide sur le transfert de connaissances avec l’intégrateur.
Le scénario : ce qui casse quand l’administrateur ERP part
Un ERP ne s’arrête pas le jour du départ. Il continue de tourner, et c’est justement le piège : le risque est silencieux. Les incidents arrivent des semaines ou des mois plus tard, quand un événement que seule la personne partie savait gérer se présente. On retrouve quatre familles de défaillances.
Les accès
L’administrateur détient souvent les comptes à privilèges : super-utilisateur applicatif, compte de base de données, comptes de service utilisés par les interfaces, accès à la console de l’éditeur. Si ces identifiants sont personnels ou stockés dans un fichier local, le départ crée deux problèmes opposés : on ne peut plus rien faire sans lui, et lui peut encore tout faire tant que ses accès ne sont pas révoqués. Le second point relève de la sécurité, traité dans notre guide sur la gouvernance des habilitations ERP.
Les interfaces et les batchs
Les flux vers la banque, la paie, le e-commerce, la logistique ou la plateforme de facturation électronique tournent grâce à des tâches planifiées, des scripts et des certificats. Une tâche nocturne qui échoue sans alerte, un certificat qui expire, un mot de passe de compte de service qui change : personne ne sait où regarder, car la logique n’est documentée nulle part.
Le paramétrage non documenté
Pourquoi ce compte comptable est-il exclu du lettrage automatique ? Pourquoi cette règle de prix s’applique-t-elle à ce client seulement ? Ces choix ont une raison, mais elle vivait dans la tête de l’administrateur. Sans elle, chaque modification devient un pari.
Le calendrier métier
La clôture mensuelle, les déclarations de TVA, les relances, les inventaires : l’administrateur connaît les enchaînements et les points de blocage habituels. Le départ tombe rarement au bon moment, et le premier mois de clôture sans lui est le vrai test.
Semaine 1 : sécuriser
L’objectif de la première semaine n’est pas de comprendre, c’est d’éviter l’irréparable. On ne cartographie rien tant que l’accès et la sauvegarde ne sont pas sous contrôle.
Comptes à privilèges
- Dressez la liste de tous les comptes administrateurs : applicatifs, système, base de données, console éditeur, comptes de service.
- Rattachez chaque compte à une identité nominative ou à un propriétaire désigné. Un compte générique sans propriétaire est un risque.
- Créez au moins deux administrateurs nominatifs côté entreprise (le nouveau DSI et un suppléant), pour ne plus dépendre d’une seule personne.
- Programmez la désactivation des accès de la personne partante à sa date de sortie, pas après.
Mots de passe et secrets
Récupérez les mots de passe de comptes techniques, clés d’API, certificats et jetons d’interface, et placez-les dans un coffre-fort de secrets géré par l’entreprise. Une fois les secrets transférés, changez-les : un secret connu d’une personne qui part doit être considéré comme compromis par principe, sans que cela suppose de mauvaise intention.
Contrats éditeur et intégrateur
Vérifiez qui est le contact nommé chez l’éditeur et l’intégrateur, quels contrats de support et de maintenance sont actifs, et à quelle adresse partent les notifications de renouvellement. Il arrive que le contact de référence soit la boîte mail personnelle de la personne partante. Faites mettre à jour les contacts et les droits d’ouverture de tickets. Pour la structure de ces contrats, voyez notre guide du contrat de TMA.
Sauvegardes testées
Une sauvegarde qu’on n’a jamais restaurée est une hypothèse. Demandez une restauration test sur un environnement séparé et notez la durée réelle. Vérifiez aussi la sauvegarde des éléments hors base : développements spécifiques, scripts, fichiers de configuration, états personnalisés.
Livrable de fin de semaine 1 : registre des comptes à privilèges, coffre-fort de secrets alimenté, contacts éditeur et intégrateur à jour, preuve d’une restauration réussie.
Semaine 2 : cartographier
Une fois le système sécurisé, on fait l’inventaire. Le but est d’obtenir une vue d’ensemble partagée, pas une documentation exhaustive. Si la personne partante est encore là, c’est la semaine où chaque heure de sa disponibilité compte : programmez des sessions courtes, filmées ou enregistrées avec son accord.
Modèle de cartographie
Copiez cette trame et remplissez-la, module par module :
- Modules actifs : lesquels sont réellement utilisés, par quels utilisateurs, avec quel niveau de licence.
- Développements spécifiques : nom, fonction, auteur, date, dernière modification, présence du code source dans un dépôt versionné.
- Interfaces : système source et cible, protocole, fréquence, format, propriétaire métier, mode de supervision, procédure de reprise en cas d’échec.
- Jobs planifiés : nom, horaire, dépendances, durée habituelle, alerte en cas d’échec, impact si le job ne tourne pas.
- Paramétrages sensibles : règles de gestion non standard, avec la raison métier quand elle est connue.
- Calendrier de clôture : jalons mensuels, trimestriels et annuels, avec les actions ERP associées et la personne qui les exécute.
- Environnements : production, recette, développement, et leur état de synchronisation.
- Contacts : éditeur, intégrateur, hébergeur, utilisateurs clés par domaine.
Pour chaque ligne, une colonne « source » indique d’où vient l’information : documentation existante, entretien, observation du système. Cela distingue le certain du supposé, ce qui sert à la semaine suivante.
Si vous préparez par ailleurs une migration, la même cartographie alimente l’audit de l’ERP existant.
Si la personne est encore là : l’entretien de transmission
Pendant le préavis, la ressource la plus rare est le temps de la personne partante. Évitez les « sessions de documentation » floues. Préparez plutôt cinq questions, posées module par module :
- Qu’est-ce qui a déjà cassé, et comment l’avez-vous réparé ?
- Quelles tâches faites-vous à la main, régulièrement, sans qu’aucun document ne les décrive ?
- Quels paramétrages ou développements ne devraient jamais être modifiés sans précaution, et pourquoi ?
- Qui, chez l’éditeur, l’intégrateur ou côté métier, est l’interlocuteur qui sait vraiment répondre ?
- Qu’est-ce qui vous inquiète sur le prochain trimestre ?
La dernière question est souvent la plus productive : elle fait remonter les risques que la personne connaît mais n’a jamais eu le temps de traiter. Enregistrez les réponses (avec accord) et rattachez-les aux lignes de la cartographie. Si le départ est conflictuel ou immédiat, le même questionnaire s’adresse à ses collègues, aux utilisateurs clés et à l’intégrateur, qui reconstituent une partie de la mémoire manquante.
Livrable de fin de semaine 2 : la cartographie remplie, avec ses zones « inconnu » assumées.
Semaine 3 : évaluer le risque
Vous avez maintenant une liste d’objets. Reste à décider lesquels méritent une action immédiate. On croise deux axes : la criticité pour l’activité (que se passe-t-il si cet élément s’arrête ?) et le niveau de connaissance disponible aujourd’hui (qui sait le réparer, et existe-t-il une documentation ?).
Matrice criticité x connaissance
Notez chaque ligne de 1 à 3 sur chaque axe. Le risque est élevé quand la criticité est forte et que la connaissance est faible. Voici un exemple de tableau à 10 lignes, à adapter à votre contexte :
| Élément | Criticité | Connaissance | Priorité |
|---|---|---|---|
| Clôture comptable mensuelle | 3 | 1 | Immédiate |
| Interface bancaire (relevés, paiements) | 3 | 1 | Immédiate |
| Flux de facturation électronique | 3 | 2 | Haute |
| Interface paie | 3 | 2 | Haute |
| Job nocturne de valorisation des stocks | 2 | 1 | Haute |
| Développement spécifique de tarification | 2 | 1 | Haute |
| Interface e-commerce | 2 | 2 | Moyenne |
| États de gestion personnalisés | 1 | 1 | Moyenne |
| Gestion des habilitations et profils | 2 | 3 | Faible |
| Environnement de recette | 1 | 2 | Faible |
Ce tableau est un exemple illustratif, pas un benchmark. Les notes viennent de vos équipes. Faites-les valider par les responsables métier : un DAF évaluera mieux que l’IT la criticité de la clôture.
Les lignes « 3 / 1 » sont vos urgences. Pour chacune, une seule question : peut-on la documenter, la tester ou la faire reprendre par un tiers avant la fin du préavis ?
Livrable de fin de semaine 3 : matrice validée, top 5 des risques avec un propriétaire et une échéance.
Semaine 4 : plan de reprise
Vous savez ce qui est critique et fragile. La dernière semaine sert à choisir comment reconstruire la capacité à gérer l’ERP.
Recruter, externaliser ou confier à l’intégrateur
| Option | Quand la privilégier | Point de vigilance |
|---|---|---|
| Recrutement d’un administrateur | ERP central, évolutions fréquentes, volume qui justifie un poste | Délai de recrutement long, période de montée en compétence |
| TMA ou régie auprès d’un prestataire | Besoin de réactivité, profil rare sur le marché | Dépendance déplacée, pas supprimée |
| Intégrateur d’origine | Projet récent, développements spécifiques lourds | Rapport de force commercial, voir le guide du transfert |
Dans la pratique, une solution mixte est courante : une personne interne qui porte la connaissance métier et l’arbitrage, adossée à un prestataire pour la profondeur technique. Veillez dans ce cas à ce que le prestataire documente ce qu’il fait.
Documentation minimale
Ne lancez pas un chantier de documentation complet. Visez le minimum utile : un runbook par processus critique de la matrice (que vérifier, comment relancer, qui appeler) et la cartographie de la semaine 2, tenue à jour.
Binôme
Désignez un suppléant pour chaque élément critique. Un binôme se vérifie : demandez au suppléant d’exécuter seul une procédure, observé par le titulaire. Si la procédure échoue, la documentation est incomplète.
Livrable de fin de semaine 4 : plan de reprise à 90 jours, choix de modèle de support, budget, premiers runbooks, binômes nommés.
Prévenir : faire en sorte que cela ne se reproduise pas
La meilleure reprise est celle qu’on n’a pas à faire. Trois pratiques réduisent durablement le risque clé-homme.
Une documentation minimale vivante. Les runbooks et la cartographie sont mis à jour à chaque changement, comme condition de clôture d’une demande d’évolution. Un document qui n’est pas relu chaque trimestre devient obsolète.
La rotation. Faites tourner les opérations sensibles (clôture, relance d’une interface) entre au moins deux personnes. La rotation révèle les lacunes tant que le titulaire est là pour les combler.
Des clauses de réversibilité. Dans les contrats avec l’éditeur, l’intégrateur et l’hébergeur, exigez la remise de la documentation, du code source des développements spécifiques et des paramétrages, et une assistance à la transition. Le sujet rejoint celui de la dépendance à l’éditeur et de la réversibilité.
Erreurs à éviter
| Erreur | Contre-mesure |
|---|---|
| Attendre le dernier jour pour agir | Lancer la semaine 1 dès l’annonce du départ, tant que la personne est disponible |
| Demander une documentation exhaustive au partant | Cibler les 5 risques de la matrice et enregistrer des sessions courtes |
| Oublier de révoquer ou de changer les accès et secrets | Intégrer la révocation à la procédure de sortie et changer les secrets partagés |
| Recruter un remplaçant sans état des lieux | Faire la cartographie et la matrice avant d’écrire la fiche de poste |
| Tout confier au prestataire sans cadre | Exiger runbooks, livrables et réversibilité dans le contrat |
Passer à l’action
Un ERP orphelin se traite plus vite qu’on ne le craint si l’on avance dans l’ordre : sécuriser, cartographier, évaluer, décider. Si vous voulez un regard externe sur votre situation, prenez contact pour un audit de votre ERP : état des lieux des accès, cartographie et matrice de risque en deux semaines environ.
Pour approfondir, lisez aussi notre guide du transfert de connaissances avec l’intégrateur et celui sur l’audit de l’ERP existant.
