Migrer un ERP métier développé sous WinDev

Un ERP métier construit sous WinDev n'est jamais un simple outil de gestion : c'est la mémoire de toutes les décisions prises par l'entreprise depuis sa mise en service. Conditions tarifaires par client, circuits de validation des commandes, exceptions négociées avec tel fournisseur : ce savoir accumulé au fil des années est souvent plus précieux que l'application qui le fait tourner.

Migrer cet ERP suppose donc, avant tout choix technique, de préserver ce savoir. Cette page détaille la méthode que nous suivons pour y parvenir sans figer votre gestion pendant des mois.

Ce constat vaut quelle que soit la taille de l'entreprise : un ERP développé en interne il y a quinze ou vingt ans porte souvent plus de logique métier qu'un observateur extérieur ne l'imagine, précisément parce qu'il a été ajusté, année après année, pour coller aux besoins réels de l'activité plutôt qu'à un standard générique.

Le vrai actif : les règles métier, pas le code

La première erreur, dans ce type de projet, consiste à réduire la migration à une question de langage de programmation. Ce qui a de la valeur dans un ERP maison, ce n'est pas la manière dont il est écrit, ce sont les règles qu'il applique : tel client bénéficie d'un tarif dégressif à partir de tel volume, telle commande déclenche automatiquement une validation supplémentaire au-delà d'un certain montant, tel fournisseur impose un délai de paiement particulier.

Ces règles se sont accumulées sur des années, souvent sans documentation à jour, et parfois sans que la personne qui les a conçues soit encore dans l'entreprise. Les perdre en migration coûterait bien plus cher que n'importe quel dépassement de budget de projet.

C'est aussi pour cette raison qu'une reprise à l'identique, fonction par fonction, est presque toujours préférable à une réécriture qui chercherait à moderniser les règles au passage. Un projet de migration n'est pas le bon moment pour remettre en cause des choix de gestion : mélanger les deux chantiers, migration technique et refonte des processus, est une source fréquente de dérapage de calendrier et de budget.

Cartographier avant de décider

Avant de choisir une trajectoire de migration, nous cartographions l'existant : les modules réellement utilisés, les règles de gestion qu'ils appliquent, les données qu'ils manipulent, les utilisateurs qui en dépendent au quotidien. Cette cartographie fait souvent apparaître des zones du logiciel qui ne sont plus utilisées depuis longtemps, et qu'il est inutile de migrer.

Elle révèle aussi les zones à risque : celles où la logique métier est la plus dense, la moins documentée, ou la plus critique pour l'activité. Ce sont ces zones qui dictent le calendrier et l'ordre de priorité du projet, pas une préférence technologique de départ.

Cette cartographie s'appuie autant sur l'analyse de l'application que sur des entretiens avec les utilisateurs métier : ce sont eux qui connaissent les exceptions non documentées, les contournements manuels et les usages réels, parfois différents de ce que l'application était censée faire à l'origine. Une cartographie purement technique, sans ce volet humain, laisse toujours des angles morts.

Faire ou acheter : ERP du marché ou sur mesure

Une fois la cartographie posée, une question se pose systématiquement : reconstruire un ERP sur mesure ou basculer vers un progiciel du marché ? La réponse dépend surtout de trois facteurs.

• Vos règles métier constituent un avantage concurrentiel réel : le sur mesure reste justifié.
• Vos processus sont proches des pratiques standard du secteur : un progiciel du marché convient bien.
• Aucun progiciel ne couvre vos règles sans adaptation lourde : le sur mesure s'impose à nouveau.

Cette décision se prend module par module plus souvent qu'on ne le pense : un module de facturation peut basculer vers un progiciel standard pendant qu'un module de production, spécifique à votre activité, reste développé sur mesure.

Migration par module

Basculer un ERP entier en une seule fois expose l'ensemble de l'activité à un même risque de projet, au même moment. Une migration par module réduit ce risque : chaque module bascule à son rythme, sur son propre calendrier, avec une phase de double fonctionnement le temps de valider que le nouveau module reproduit fidèlement le comportement de l'ancien.

Cette approche demande une interface stable entre les modules déjà migrés et ceux qui restent sur l'ancienne base, ce qui est un point de conception à traiter dès le début du projet, pas en cours de route.

L'ordre de migration des modules se décide en fonction de deux critères : le niveau de risque métier et le niveau de dépendance envers les autres modules. Commencer par un module isolé, peu critique, permet de valider la méthode et l'outillage avant de s'attaquer aux modules centraux, ceux dont dépend l'essentiel de l'activité quotidienne.

Interfaces avec la comptabilité, la paie, la logistique

Les interfaces entre l'ERP et les systèmes périphériques sont souvent le point le plus fragile d'une migration, précisément parce qu'elles sont nombreuses et parfois peu documentées. Une exportation comptable qui fonctionne depuis dix ans, un flux vers le logiciel de paie, un échange automatisé avec un prestataire logistique : chacune de ces connexions doit être identifiée avant la migration, pas découverte après coup lorsqu'un flux cesse silencieusement de fonctionner.

Notre méthode consiste à lister systématiquement ces interfaces pendant la phase de cartographie et à valider chacune d'elles individuellement avant la bascule définitive du module concerné.

Un point mérite une attention particulière : certaines de ces interfaces reposent sur des exports de fichiers à format fixe, mis en place il y a longtemps et jamais revus depuis. Elles fonctionnent, mais personne dans l'entreprise ne sait toujours précisément pourquoi elles ont cette forme. Les documenter avant la migration évite de reproduire une fragilité invisible dans le nouveau système.

Cas client

Nous détaillons des exemples concrets de migration d'ERP métier, secteur par secteur, sur la page dédiée à nos études de cas.