De l'AS/400 à Linux : retour d'expérience sur une migration d'ERP iSeries vers Dolibarr sans interruption d'activité

Beaucoup de PME font tourner leur activité sur un ERP propriétaire installé sur un IBM AS/400 (iSeries). Ces systèmes ont un mérite : ils fonctionnent, parfois depuis vingt ans. Mais ils finissent par poser les mêmes questions à leurs dirigeants : des coûts de maintenance qui grimpent, un matériel de plus en plus difficile à faire évoluer, une dépendance forte à un éditeur, et l'impossibilité d'adapter facilement l'outil aux besoins réels du terrain.

La vraie question pour un décideur n'est pas « est-ce qu'une alternative existe ? », elle existe, mais « est-ce que je peux en changer sans prendre un risque déraisonnable pour mon exploitation ? ». Quand votre système traite plusieurs milliers de commandes par an, une migration ratée n'est pas une option.

Voici comment nous avons mené ce changement pour l'un de nos clients, et pourquoi l'approche progressive que nous avons retenue a rassuré tout le monde.

Le contexte client

Notre client est une entreprise française de négoce B2B, réalisant entre 5 et 10 M€ de chiffre d'affaires, avec près de 10 000 commandes et autant de factures par an. Un volume d'activité significatif, où chaque heure d'indisponibilité du système se traduit immédiatement en commandes non saisies et en livraisons retardées.

Son ERP historique, propriétaire, tournait sur un IBM AS/400. Le système était vieillissant et ses coûts de maintenance, logiciel comme matériel iSeries, devenaient difficiles à justifier. L'objectif était clair : sortir de cette dépendance pour reprendre la main sur l'outil et sur les coûts, en basculant vers Dolibarr, un ERP open source, hébergé sur un serveur GNU/Linux.

L'enjeu : changer d'ERP sans tout arrêter

Le piège classique d'un changement d'ERP, c'est la bascule « big bang » : on prépare le nouveau système pendant des mois, on choisit une date, on éteint l'ancien le vendredi soir et on espère que tout fonctionne le lundi matin. Sur une entreprise qui saisit des milliers de commandes, ce scénario est anxiogène pour les dirigeants, déstabilisant pour les équipes, et difficilement réversible en cas de problème.

Nous avons fait le choix inverse : une migration progressive, par étapes, où l'ancien système reste maître des données métier aussi longtemps que nécessaire, pendant que le nouveau prend en charge les fonctions une à une. À chaque étape, on valide, on rassure, et on garde la possibilité de revenir en arrière. C'est cette méthode qui a permis de mener le projet sereinement.

Les grandes étapes de la migration

Le plan d'action s'est déroulé en plusieurs phases successives, chacune validée avant de passer à la suivante.

1. Récupération des données et premiers tests. Nous avons commencé par extraire les données de l'ERP AS/400 pour alimenter une première base Dolibarr. Cette base a servi à valider les fonctionnalités de base, saisie de commande, facturation, dans des conditions proches du réel, sans toucher au système de production.

2. Une synchronisation pour rester au plus près du réel. Une base de test figée vieillit vite et ne reflète plus l'activité. Nous avons donc mis en place une synchronisation de l'AS/400 vers Dolibarr, afin de maintenir en permanence une base de test à jour. Les équipes pouvaient ainsi évaluer le nouvel outil sur des données vivantes, sans aucun risque pour l'exploitation.

3. L'implication des utilisateurs. Plutôt que de leur imposer un outil, nous avons associé les utilisateurs très tôt pour identifier précisément les écarts entre Dolibarr et leurs habitudes de travail, et les améliorations réellement nécessaires. Ce sont eux qui connaissent le métier.

4. Un module Dolibarr sur mesure. Sur la base de ces retours, nous avons développé un module Dolibarr spécifique, prenant en charge les adaptations indispensables au métier du client. L'open source nous a permis ici une liberté d'adaptation qu'un ERP propriétaire fermé n'autorise pas.

5. La saisie de commande bascule dans Dolibarr. Première vraie bascule fonctionnelle : nous avons ajouté une synchronisation des commandes de Dolibarr vers l'AS/400, afin que la saisie puisse se faire directement dans Dolibarr, une interface jugée plus simple par le service administration des ventes. Point clé : à ce stade, l'AS/400 reste maître des données métier. On gagne en confort sans rien risquer sur le fond.

6. La facturation suit. Quelques semaines plus tard, une fois la saisie de commande maîtrisée et adoptée, la facturation a elle aussi été prise en charge par Dolibarr. Les éléments comptables sont transmis au logiciel de comptabilité, qui reste externalisé : chaque brique reste à sa place.

7. Un logiciel sur mesure pour le stock et la préparation. La gestion de stock et la préparation de commandes étaient trop spécifiques pour se contenter d'un module standard. Nous avons développé un logiciel dédié à ce domaine, connecté à Dolibarr par API : les fiches produit, les commandes et les expéditions restent gérées par Dolibarr, le sur-mesure se concentre sur la logistique.

8. Le débranchement progressif de l'AS/400. Après tests et validation par les utilisateurs, la gestion de stock et la préparation de commandes ont été débranchées de l'AS/400, désormais prises en charge exclusivement par Dolibarr et le logiciel sur mesure.

9. L'arrêt complet de l'ancien système. Une fois la dernière fonction migrée et éprouvée, l'AS/400 a pu être complètement arrêté. La sortie de l'ERP propriétaire et du matériel iSeries était achevée, sans rupture, et avec des équipes déjà à l'aise sur les nouveaux outils.

L'infrastructure retenue

Le client souhaitait conserver la maîtrise de son infrastructure, un choix tout à fait légitime, en particulier sur un système aussi central que l'ERP. Dolibarr fonctionne donc sur un serveur interne à l'entreprise, dimensionné pour son activité :

• Processeur Intel Xeon E3-1245 V2
• 16 Go de RAM
• 1 To de disque en RAID 1
• Sauvegarde externalisée

La répartition des responsabilités a été pensée pour rester simple et efficace : Befox assure l'administration système de la machine, tandis que la partie matérielle est confiée à un prestataire local, déjà en charge du reste du réseau et géographiquement plus proche. Chacun intervient là où il est le plus pertinent.

Le bénéfice de l'approche par étapes

Si ce projet s'est bien passé, c'est avant tout grâce à la méthode. Le découpage en étapes agiles a permis un mode de fonctionnement à la fois sécurisé et progressif, qui a convenu à tous les intervenants :

• Les décideurs ont été rassurés : à aucun moment l'activité n'a été mise en péril, et chaque étape était réversible.
• Les utilisateurs ont pris en main les nouveaux outils progressivement, en participant aux choix, plutôt que de subir une bascule du jour au lendemain.
• Befox a pu réaliser des mises en production plus simples et plus fiables, en validant chaque fonction avant de passer à la suivante.

Au bout du chemin : un ERP open source maîtrisé, une infrastructure sous contrôle du client, des coûts de maintenance assainis, et la fin de la dépendance à un matériel et un logiciel propriétaires en fin de vie.

Ce que cela signifie pour vous

Si vous faites tourner votre activité sur un ERP AS/400 vieillissant, le statu quo n'est pas votre seule option, et en sortir n'oblige pas à prendre un risque industriel. Une migration bien conçue se mène par étapes, en laissant l'ancien système maître des données aussi longtemps qu'il le faut, et en embarquant les équipes plutôt qu'en leur imposant le changement.

C'est exactement ce type de projet que nous accompagnons chez Befox : audit de l'existant, stratégie de migration, développements sur mesure, et administration système dans la durée.

Vous vous posez la question pour votre propre ERP ? Parlons-en, un premier échange suffit souvent à dégager une trajectoire réaliste.