Changement d'intégrateur ERP: la méthode de reprise, illustrée par Business Central

Qu'il s'agisse de SAP, de Sage X3 ou de Business Central, la reprise d'un projet ERP par un nouvel intégrateur suit presque toujours le même scénario. Le système fonctionne, plus ou moins, mais la connaissance de ce qui a été construit est partie avec l'équipe précédente. Il faut la récupérer, y compris ce qui n'a jamais été écrit, sans interrompre la facturation, les achats ni la clôture du mois. Les raisons du changement varient: relation dégradée, partenaire racheté, consultant clé parti, ou volonté de reprendre en interne une partie de la maintenance.

Un projet Business Central permet d'illustrer chacune de ces difficultés. Un lundi matin, le nouveau partenaire ouvre le centre d'administration. Il y trouve trois environnements Sandbox dont personne ne connaît l'usage, une extension développée pour le client sans code source disponible et un accès administrateur délégué qui expire dans dix jours. Le prestataire sortant a facturé sa dernière journée de régie la semaine précédente.

Manifestations et symptômes sur le terrain

Sur tout ERP, les premiers signaux viennent des traitements automatiques que plus personne ne surveille. Dans Business Central, ils apparaissent dans la page "Écritures file d'attente des travaux": une relance clients ou un export comptable y reste en statut "Erreur" depuis des semaines. L'ancien consultant relançait la tâche à la main chaque lundi, sans jamais l'avoir signalé.

Viennent ensuite les développements spécifiques dont le code n'a jamais été livré. Dans notre projet Business Central, une extension figure bien dans la page "Gestion des extensions", mais sa politique d'exposition interdit d'en télécharger le code depuis l'environnement. Le nouveau partenaire peut l'exécuter, pas la corriger. À la mise à jour majeure suivante, en avril ou en octobre, un objet standard retiré par Microsoft suffit à bloquer son installation.

Les équipes métier ont, de leur côté, construit leurs propres parades. Un fichier Excel recalcule les commissions que l'ERP calcule mal, et une comptable corrige un champ avant chaque validation de facture. Ces gestes ne figurent dans aucun document. On les découvre le jour où la personne part en congés.

Impact financier, opérationnel et humain

Le coût le plus visible tient au temps passé à comprendre avant de pouvoir agir. Une anomalie que l'équipe sortante réglait en une heure peut demander deux jours d'analyse à celle qui reprend le dossier, et ces journées sont facturées. Quand un développement spécifique doit être réécrit faute de code source, la facture change d'échelle.

L'exploitation encaisse elle aussi le choc. Une interface EDI arrêtée, ou une synchronisation bancaire qui échoue sans alerte, et les opérations du jour ne sont pas intégrées. La première clôture mensuelle après la reprise sert souvent de révélateur: le contrôleur de gestion constate des écarts de stock que plus personne ne sait expliquer.

Pour les collaborateurs, la reprise ressemble à une remise à zéro. Ils doivent réexpliquer des processus qu'ils pensaient acquis, et leur confiance dans l'outil baisse au moment précis où le nouveau partenaire en aurait besoin.

Analyse des causes racines et erreurs de gouvernance

Accuser le partenaire sortant serait commode. La réalité est plus partagée. Le contrat initial ne prévoyait souvent ni clause de réversibilité, ni livraison du code des développements, ni documentation d'exploitation, et l'entreprise ne les a jamais réclamées tant que tout fonctionnait. Le partenaire sortant, lui, a peu d'intérêt à consacrer du temps non facturé à former son successeur.

L'erreur de gouvernance la plus fréquente consiste à confondre la date de fin du contrat avec la date de prise en charge. Le nouveau partenaire démarre le support sans période de recouvrement et apprend le système en traitant les incidents. Les droits d'administration changent de main à la dernière minute, parfois après la coupure des accès de l'ancien partenaire. Sur Business Central, il s'agit des droits délégués (GDAP) et des licences CSP, sans lesquels le nouveau partenaire ne peut même pas ouvrir le centre d'administration.

Reste la connaissance tacite. Une partie du paramétrage repose sur des choix faits en atelier il y a des années, jamais consignés. Seuls deux ou trois utilisateurs clés en connaissent encore la raison, et personne ne les a identifiés comme les gardiens d'un savoir critique.

Plan d'action, mesures préventives et correction

La reprise se négocie avant la signature du nouveau contrat. On obtient de l'ancien partenaire une période de tuilage, de deux à six semaines selon le périmètre, pendant laquelle les deux équipes traitent ensemble les incidents réels. Les premiers ateliers recensent les sociétés, les sites et les entités juridiques exploités, avec leurs particularités: Intrastat, plan comptable d'une filiale étrangère, circuit de validation propre à un dépôt.

La cartographie couvre ensuite les environnements, les développements spécifiques et les interfaces. Pour chaque développement, on note son auteur, sa nature et l'emplacement de son code source. Dans Business Central, cela revient à distinguer les apps AppSource des extensions propres au client, puis à passer le code AL au crible pour repérer les objets marqués obsolètes, qui annoncent les ruptures des prochaines mises à jour. Les interfaces avec les banques, l'EDI, le site e-commerce ou la paie sont relevées avec leur fréquence et leur propriétaire.

Si le système tourne déjà en production, l'historique des tickets et les traitements en erreur en disent plus long que n'importe quel dossier; sur Business Central, la télémétrie Application Insights, quand elle est activée, complète le tableau. Si le projet est encore en déploiement, le diagnostic porte plutôt sur l'état des recettes dans l'environnement de test: scénarios validés, scénarios à rejouer, anomalies ouvertes. Chaque étape produit son livrable au fil de l'eau, ce qui évite le classeur de quatre-vingts pages remis le dernier jour et jamais relu.

La bascule n'a lieu qu'une fois ces conditions réunies:

• code source de tous les développements spécifiques livré dans un repository dont le client est propriétaire;
• droits d'administration et licences transférés au nouveau partenaire, soit GDAP et CSP pour Business Central;
• aucun traitement planifié en erreur inexpliquée;
• procédures d'urgence testées et contacts d'escalade connus, chez l'éditeur de l'ERP comme chez les éditeurs d'apps tierces.

Le plan de bascule attribue ensuite chaque action à un responsable, avec une procédure de repli. Les utilisateurs clés reçoivent le nouveau circuit de demande d'assistance la veille, pas le lendemain.

Conclusion

Une reprise de projet ERP se gagne ou se perd avant le premier ticket. L'entreprise qui accepte un démarrage du support sans code source, sans accès administrateur et sans tuilage achète un risque qu'elle paiera à la prochaine montée de version. Sur Business Central, cette échéance revient deux fois par an. La méthode n'a de valeur que si l'on refuse de brûler les étapes.

La première mesure ne coûte rien. La direction relit son contrat d'intégration en cours, vérifie qu'il prévoit la réversibilité et la propriété du code des développements spécifiques, puis demande où se trouve ce code aujourd'hui. Si personne ne sait répondre, la reprise a déjà commencé, sans que personne ne l'ait décidée.