Migrer depuis Batigest sans perdre ses données : la méthode

Une entreprise qui utilise Batigest depuis dix ans y a construit un patrimoine : le fichier clients, l'historique des devis et des factures, et surtout une bibliothèque d'articles et d'ouvrages enrichie chantier après chantier. La question posée à toute migration porte sur ce patrimoine, jamais sur le logiciel lui-même.

Ce qui suit porte sur la conduite du projet. L'inventaire de ce qui sort techniquement de l'ancien outil est traité à part dans sortir ses données de Batigest.

Préparer avant de transférer

Trois gestes préalables, dans cet ordre, avant que quiconque touche à un import.

Une copie de sauvegarde datée. La génération i7 stocke ses données dans une base de type Access, la génération suivante sur SQL Server. Dans les deux cas, la copie du dossier de données est votre point de retour. Elle se fait un soir, elle se range en double exemplaire, elle ne se néglige pas.

Un inventaire de ce qui doit passer. Tout ne mérite pas d'être repris. La bibliothèque et les tiers, oui, intégralement. Les chantiers ouverts, oui, avec leurs cumuls. Les affaires soldées depuis six ans, non : elles relèvent de l'archive, dont le régime est décrit dans archiver son ancien logiciel.

Un jeu d'essai représentatif. Cinq ouvrages complexes, un devis long à plusieurs niveaux de postes, une facture avec retenue de garantie, une fiche client chargée. Ce jeu servira de recette et vaut mieux qu'un échantillon aléatoire.

L'ordre qui évite les liens orphelins

Une reprise se fait du plus stable au plus dépendant. L'inverser produit des références qui pointent dans le vide, et ces liens cassés se réparent un par un, à la main.

1. Les articles et les ouvrages d'abord, puisque tout le reste y fait référence.
2. Les tiers, clients et fournisseurs, socle des documents commerciaux.
3. Les devis, rattachés aux tiers et aux ouvrages déjà en place.
4. Les documents de facturation, en dernier, pour clore l'historique.

Cet ordre n'est pas une préférence d'organisation, c'est une contrainte de structure. Un devis importé avant sa bibliothèque perd la composition de ses lignes, ce qui revient à importer un prix figé.

Les trois pièges documentés

Ces trois points sont décrits noir sur blanc dans les documentations d'import publiées par des revendeurs, et ils se retrouvent d'un outil à l'autre.

La profondeur des ouvrages. Un import documenté publiquement limite les structures d'ouvrages à deux niveaux, avec perte d'information au-delà (monpartenaire-codial.fr). Vérifiez sur vos ouvrages imbriqués avant de valider quoi que ce soit : c'est le point qui fait la différence entre une bibliothèque vivante et un catalogue de prix morts.

Les arrondis. Les politiques de calcul diffèrent d'un moteur à l'autre, ligne par ligne ou sur le total, ce qui produit des écarts de montants sur les devis repris. Ces centimes se constatent sur un échantillon, une règle se décide, et le sujet est clos. Découverts sur un devis déjà envoyé, ils coûtent une explication au client.

L'encodage des caractères. Les bases anciennes n'utilisent pas le même jeu de caractères que les outils actuels. Sans correction, les accents des désignations d'ouvrages ressortent abîmés, sur des milliers de lignes.

La recette : cinq contrôles avant la bascule

Une reprise se valide, elle ne se croit pas sur parole. Cinq contrôles, à passer dans cet ordre.

1. Comptage. Nombre de clients, de fournisseurs, d'articles, d'ouvrages et de devis, comparé des deux côtés. Un écart s'explique avant d'aller plus loin.
2. Composition. Ouvrir trois ouvrages complexes et vérifier leur recette ligne à ligne, temps de main-d'œuvre compris.
3. Montants. Recalculer trois devis repris et comparer les totaux à l'original. Les écarts attendus sont en centimes, pas en euros.
4. Libellés. Rechercher les caractères parasites dans les désignations, signe d'un encodage non corrigé.
5. Chaînage. Prendre un chantier et remonter du devis à la facture en passant par les situations. Si la chaîne tient, la structure est bonne.

Ces contrôles se mènent sur une reprise d'essai, avant la reprise définitive, sur une copie. Personne ne devrait découvrir un défaut de structure une fois les équipes en production.

Le moment de basculer

La bascule se décide, elle ne se subit pas. Pendant la période de recouvrement, l'ancien outil sert à lire et le nouveau à écrire, deux à quatre semaines au maximum. Au-delà, la double saisie s'installe et produit deux historiques qui divergent.

Le cas des chantiers ouverts et des situations de travaux en cours mérite un traitement à part, parce qu'il touche directement à ce qui est facturé : il est détaillé dans changer de logiciel avec des chantiers en cours.

Faire de la migration une occasion

Une reprise bien préparée est le bon moment pour un ménage que personne ne fait jamais : archiver les clients inactifs, fusionner les doublons d'articles, retirer les ouvrages qui ne servent plus, relancer les devis oubliés. On repart avec une base à jour plutôt qu'avec dix ans de scories, et le tri se rentabilise dès les premières semaines.

C'est aussi le moment de trancher la question de fond du tout-en-un contre l'empilement d'outils, si Batigest cohabitait jusqu'ici avec un tableur de planning et un logiciel de comptabilité séparé. La correspondance fonction par fonction est posée dans Batigest poste par poste.

Sur une reprise vers StrucTime, c'est cette démarche qui est appliquée : lecture de la base d'origine, reconstitution des ouvrages avec leurs sous-lignes, correction de l'encodage, contrôle des arrondis, recette validée par l'entreprise, puis bascule. L'historique change de maison, il ne se perd pas.

Questions fréquentes

Peut-on vraiment tout récupérer de Batigest ? Le socle se reprend : clients, fournisseurs, articles, ouvrages, devis. La qualité du résultat dépend de la capacité de l'outil d'arrivée à reconstituer la hiérarchie des ouvrages, qui est le point où les reprises se distinguent. Le détail par type de donnée est dans sortir ses données de Batigest.

Combien de temps prend une migration depuis Batigest ? Cela dépend du volume et de l'état de la base, et aucun délai standard ne serait honnête. Ce qui se planifie en revanche, c'est le déroulé : sauvegarde, reprise d'essai, recette, corrections, reprise définitive, bascule. Une trame en cinq semaines est proposée dans changer de logiciel avec des chantiers en cours.

Que faire des écarts d'arrondi après import ? Les constater sur un échantillon de devis, choisir une règle de calcul cohérente, la documenter, puis reprendre la production. Ces écarts sont attendus dès qu'on change de moteur de calcul.

Faut-il garder Batigest accessible après la migration ? Le temps de valider la recette, oui. Ensuite, ce qui compte est l'archive constituée à part, lisible sans le logiciel, avec les délais de conservation rappelés dans archiver son ancien logiciel.

Par où commencer si la décision n'est pas prise ? Par le calendrier. Les dates publiées par l'éditeur et les trois voies possibles sont réunies dans Batigest i7 s'arrête : le calendrier.