Réponse courte. Reprendre ses données n'est pas un import la veille du lancement : c'est un chantier de six semaines mené en parallèle de la construction de l'application. Il commence par un inventaire des sources et de ce qui fait foi, puis une table de correspondance signée : d'où vient chaque champ, avec quelle règle, et ce qu'on laisse derrière. Le nettoyage prend plus de temps que tout le reste : noms, téléphones, dates et montants normalisés, doublons fusionnés par règle, et les valeurs que le tableur a abîmées, une date devenue nombre, un identifiant de vingt chiffres tronqué à quinze, redemandées et jamais devinées. Tout est ensuite chargé à blanc trois fois dans une copie, avec un rapport des rejets. La preuve que rien n'est perdu est un rapprochement : nombre de clients, factures ouvertes, solde total, stock, égaux dans l'ancien et le nouveau. La bascule se fait en un week-end, ancien système en lecture seule, avec un retour arrière daté. On ne reprend que ce qui vit encore ; le reste s'archive.
Ce guide s'adresse au gérant en Algérie dont l'activité tient dans des classeurs Excel et un logiciel de dix ans, au fondateur installé en France qui reprend une entreprise familiale et ses fichiers, et à celui qui compare des devis où « migration des données » tient en une ligne. Il ne traite pas de la connexion permanente entre deux logiciels, décrite dans le guide sur l'intégration ; il décrit le passage, fait une fois, de l'ancien au nouveau.
Ce que les chiffres disent
Un tableur stocke ce qu'on lui tape, et il a ses limites écrites. La page des spécifications d'Excel publiée par Microsoft donne une feuille de 1 048 576 lignes sur 16 384 colonnes, une précision numérique de quinze chiffres, et des dates calculées à partir du 1er janvier 1900. Ces trois lignes expliquent trois pannes de reprise. Les dates sont des nombres : 45123 est le 16 juillet 2023, et une colonne exportée sans son format arrive comme une suite de nombres. Un identifiant de plus de quinze chiffres saisi comme un nombre perd ses derniers chiffres, remplacés par des zéros : c'est le cas d'un RIB de vingt chiffres, et aucune règle ne les retrouve. Et un fichier qui dépasse le million de lignes a été coupé en plusieurs, quelque part.
Les dates ont une autre surprise, documentée. Microsoft explique qu'Excel considère à tort 1900 comme une année bissextile, par compatibilité avec le tableur Lotus 1-2-3, et que corriger ce comportement décalerait d'un jour presque toutes les dates des classeurs existants ; il existe aussi un second système de dates qui commence en 1904. Ce que cela impose : la conversion des dates se fait avec la règle du tableur, pas avec une soustraction naïve, et elle se vérifie sur des dates connues, la date de création de l'entreprise, la première facture, avant d'être appliquée à cent mille lignes.
Le chargement lui-même est la partie facile. La documentation de PostgreSQL recommande de charger les lignes avec la commande de copie en masse plutôt qu'une série d'insertions, parce qu'elle a « nettement moins de surcoût pour les gros chargements », de créer les index après le chargement, et de lancer l'analyse des tables ensuite ; un chargement dans une seule transaction a un autre avantage, écrit dans la même page : si une ligne échoue, tout est annulé, et l'on n'est pas « coincé avec des données partiellement chargées ». Ce que cela impose : cent mille factures se chargent en minutes, et tout le temps du chantier est ailleurs, dans le nettoyage et le rapprochement. Ce que nous n'avons pas trouvé : une statistique sur l'état des fichiers des entreprises algériennes ; ce que nous voyons, c'est qu'un fichier clients de dix ans contient en général quelques pour cent de doublons, et nous le disons comme une observation.
Deux lignes Excel deviennent une fiche client
La reprise ne se comprend pas sur un schéma de bases de données mais sur deux lignes d'un vrai fichier.
Le nom : « sarl el baraka » avec une espace à la fin et « EL-BARAKA (SARL) » sont le même client ; la casse, les espaces et les tirets sont normalisés, et la forme juridique part dans son propre champ. Le téléphone : deux numéros dans la même cellule, l'un avec le zéro, l'autre sans ; un numéro par champ, au format international avec l'indicatif +213, celui qui servira à la connexion décrite dans le guide sur l'OTP. La date : 45123 dans une ligne et 16/07/23 dans l'autre sont la même date ; la première est convertie depuis le numéro de série du tableur, la seconde est lue avec le format du poste qui l'a saisie, et quand le jour et le mois peuvent s'inverser, la ligne est listée.
L'identifiant bancaire : vingt chiffres saisis comme un nombre, affichés en notation scientifique, dont les cinq derniers sont perdus ; la seconde ligne l'a en texte mais tronqué ; il est marqué « à redemander au client » et la fiche entre sans lui. Aucune règle ne reconstruit un chiffre perdu, et une application qui devine un RIB est une application qui envoie un virement au mauvais compte. La ville : « blida » et « Blida ctr » sont rattachées au code de wilaya 09. La fusion : les deux lignes ont le même téléphone et un nom proche ; elles deviennent une fiche, leurs soldes s'additionnent, et les deux lignes d'origine restent attachées à la fiche pour qu'on puisse défaire la fusion.
La reprise des données, en six étapes
Derrière ces deux lignes, six étapes, et la troisième prend plus de temps que les cinq autres.
L'inventaire liste chaque source, qui la tient, depuis quand, et surtout ce qui fait foi quand deux sources se contredisent : le fichier du comptable ou celui du commercial. La correspondance est une table, colonne par colonne : d'où vient chaque champ de la nouvelle application, avec quelle règle de transformation, et ce qui est laissé derrière ; elle est signée par le gérant, et elle sert aussi aux développeurs, qui y découvrent les champs que l'activité utilise vraiment. Le nettoyage applique les règles, détecte les doublons, et produit la liste de ce qui ne peut pas être réparé et doit être redemandé ; cette liste part aux équipes dès la deuxième semaine, parce que rappeler deux cents clients prend du temps.
Le chargement à blanc charge tout dans une copie de la nouvelle application, chronomètre l'opération, et produit un rapport : tant de lignes entrées, tant de rejetées, et pourquoi. Il se fait trois fois : le premier révèle les règles oubliées, le deuxième les corrige, le troisième est la répétition générale de la bascule. Le rapprochement compare des totaux entre l'ancien et le nouveau. La bascule suit un déroulé écrit heure par heure, répété, avec un retour arrière. Le tout se déroule pendant que l'application se construit, selon la méthode par lots décrite dans le guide sur la livraison.
«Aucune règle ne reconstruit un chiffre perdu : ce que le tableur a abîmé se redemande, il ne se devine pas.»
La bascule en un week-end
La bascule est le moment où l'entreprise change de système ; elle tient en un week-end parce que tout ce qui pouvait échouer a déjà échoué trois fois.
Vendredi 18 h, l'ancien système passe en lecture seule : on peut consulter, on ne saisit plus ; c'est ce qui garantit que les chiffres comparés le lendemain ne bougent pas. Samedi, le dernier chargement, identique au troisième chargement à blanc, puis le rapprochement. Samedi soir, quatre chiffres sont lus des deux côtés : le nombre de clients actifs, les factures ouvertes une par une, le solde total des clients au dinar près, les références en stock avec leurs quantités par dépôt. Ils sont égaux, ou l'on n'ouvre pas lundi. Les doublons fusionnés ne sont pas un écart : ils sont listés, avec les lignes d'origine.
Lundi 8 h, la nouvelle application ouvre, et l'ancien reste consultable. Jusqu'à lundi midi, le retour arrière est possible : l'ancien système repasse en écriture et la matinée est ressaisie ; passé cette heure, les nouvelles saisies sont trop nombreuses et l'on corrige en avant. Cette heure limite est écrite avant le week-end, pas décidée dans l'urgence. La semaine suivante, les équipes signalent les écarts qu'elles voient, un client introuvable, un solde contesté, et chacun est tracé jusqu'à sa ligne d'origine ; la sauvegarde datée de l'ancien système est gardée, comme le guide sur l'hébergement le prévoit.
Six sources, comment on les récupère et ce qu'on contrôle
Six sources que nous rencontrons, et pour chacune la façon de la lire et ce qu'on y contrôle.
Les fichiers Excel se lisent feuille par feuille, en écartant les cellules fusionnées, les totaux en bas de colonne et les lignes de titre qui se font passer pour des données ; on y contrôle les dates en nombres, les identifiants longs, les zéros de tête et l'encodage de l'arabe. L'ancien logiciel avec une base se lit par export ou en lecture seule, sans jamais y écrire ; on y trouve des champs détournés de leur usage, le champ « fax » qui contient le nom du commercial, et des codes sans libellé. Le logiciel sans export se reprend par ses impressions en PDF, relues comme dans le guide sur la lecture de documents, avec le total de chaque état comme chiffre de contrôle.
Le papier et les carnets sont photographiés et lus, ou saisis à la main, avec une double saisie sur un échantillon et des soldes confirmés auprès des clients concernés. Plusieurs fichiers par agence demandent de construire une clé commune, téléphone et identifiant, parce que le même client y figure sous trois noms. Les messages et les photos ne se reprennent que pour ce qui a encore un effet, un solde ouvert, une commande non livrée. Et tout ne se reprend pas : dix ans de commandes livrées et payées restent consultables dans une archive ; ce qui doit entrer propre, c'est ce qui vit encore, clients, produits, soldes, stock, commandes ouvertes.
«La preuve que rien n'est perdu, ce sont quatre totaux lus le samedi soir, égaux des deux côtés.»
Six pièges de la reprise
Six pièges que nous voyons sur les reprises que nous rattrapons, et ce que la méthode fait contre chacun.
Le doublon : le même client existe trois fois et son solde est réparti ; clé sur le téléphone et l'identifiant, noms comparés avec tolérance, fusion par règle, liste validée par le gérant. La date devenue nombre : conversion depuis le numéro de série du tableur, et les dates dont le jour et le mois peuvent s'inverser listées plutôt que devinées. L'identifiant abîmé : détecté par sa longueur et ses zéros de fin, redemandé au client, jamais reconstruit.
Le solde qui ne tombe pas juste : le total des soldes clients diffère de celui de la comptabilité avant même la reprise ; l'écart est expliqué ligne par ligne, ou la bascule attend, parce qu'un écart importé devient un écart inexplicable. L'arabe illisible : les noms deviennent des points d'interrogation ; l'encodage est détecté fichier par fichier, converti, et vérifié à l'œil sur un échantillon. La bascule sans retour : un chiffre est faux lundi et l'ancien système a été modifié entre-temps ; lecture seule, sauvegarde datée, retour arrière écrit avec son heure limite. Les trois premiers viennent du tableur lui-même ; les trois derniers, de la méthode ; aucun ne se voit avant le premier chargement à blanc.
Vu ailleurs : les limites d'Excel, PostgreSQL, et ce qui se transpose
Deux sources disent l'essentiel. Les spécifications d'Excel disent qu'un nombre n'a que quinze chiffres de précision et que les dates sont des nombres comptés depuis 1900, avec une année bissextile de trop ; ce qui se transpose, c'est que trois des six pièges ne sont pas des erreurs de saisie mais le comportement normal du tableur, et qu'ils se traitent par des règles, pas en reprochant le fichier à l'équipe. La documentation de PostgreSQL dit que le chargement en masse est rapide et qu'une transaction unique annule tout en cas d'échec ; ce qui se transpose, c'est qu'on peut charger trois fois sans crainte, et qu'un chargement à moitié fait n'existe pas.
Ce que ces sources ne disent pas : quelles sources vous avez, laquelle fait foi, combien de doublons, et quels chiffres votre comptable veut voir égaux le samedi soir ; la première semaine du projet y répond, avec les fichiers ouverts sur la table.
Les règles d'une reprise qui ne perd rien
Six règles, écrites la première semaine. La reprise commence avec le projet, pas à la fin. Une table de correspondance signée : chaque champ a une source et une règle, ou il est laissé derrière par écrit. On ne devine jamais : ce qui est abîmé est listé et redemandé. Trois chargements à blanc, chronométrés, avec rapport des rejets. Le rapprochement fait foi : des totaux égaux des deux côtés, choisis avec le comptable, ou la bascule attend. Un retour arrière écrit, avec son heure limite, et l'ancien système en lecture seule.
Une septième règle porte sur le devis : « migration des données » n'est pas une exigence, c'est une ligne ; l'exigence s'écrit « inventaire des sources, table de correspondance validée, règles de nettoyage et de fusion des doublons, liste des valeurs à redemander, trois chargements à blanc avec rapport des rejets, rapprochement sur tels totaux, bascule en un week-end avec déroulé et retour arrière, archive consultable de l'historique non repris », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui chiffre « un import Excel » a chiffré le chargement, pas la reprise.
Six entreprises, et ce qu'on reprend d'abord
Six entreprises que nous accompagnons souvent, et pour chacune ce qui se reprend en premier.
- Le grossiste et le distributeur, avant d'ouvrir le portail décrit dans le guide dédié. Clients avec leur solde et leur plafond, catalogue avec les prix par client, stock par dépôt ; l'historique des commandes en archive.
- La clinique et le cabinet, décrits dans le guide sur le cabinet. Patients dédoublonnés sur le téléphone et la date de naissance, rendez-vous à venir, plans de traitement ouverts ; les dossiers anciens scannés et rattachés.
- L'agence immobilière et l'espace propriétaire, décrits dans le guide dédié. Biens, propriétaires, baux en cours, loyers impayés ; les quittances passées en archive.
- L'école privée. Élèves et parents avec leurs téléphones normalisés, inscriptions de l'année, échéances restant dues.
- L'éditeur de SaaS, décrit dans le guide sur le multi-tenant. Un outil d'import par client, avec la même table de correspondance et le même rapport des rejets, parce que chaque nouveau client arrive avec ses fichiers.
- L'entreprise reprise depuis la France. Tout ce qui tient dans la tête et les classeurs du gérant précédent : la reprise est aussi le moment où l'on découvre ce que l'entreprise sait d'elle-même, et le tableau de bord décrit dans le guide dédié en sort.
Le calendrier 2027
Le calendrier est celui d'une reprise complète en six semaines, menée pendant que l'application se construit.
La semaine 0 à 1 fait l'inventaire et la correspondance : toutes les sources, ce qui fait foi, la table colonne par colonne, ce qui est repris, archivé ou laissé ; signés. Les semaines 1 à 3 écrivent le nettoyage : règles de normalisation, détection des doublons, et la liste des valeurs à redemander envoyée aux équipes dès qu'elle existe. La semaine 3 à 4 fait le premier chargement à blanc, avec son rapport des rejets et un premier rapprochement presque toujours faux, ce qui est son rôle.
La semaine 4 à 5 fait le deuxième et le troisième : règles corrigées, doublons validés un par un par le gérant quand la règle hésite, durée mesurée, rapprochement juste. La semaine 5 à 6 est la bascule et le suivi : le week-end, l'ouverture, et une semaine à tracer chaque écart signalé jusqu'à sa ligne d'origine. Les noms et produits nettoyés servent aussi à la recherche, dont la normalisation est décrite dans le guide sur la recherche.
Ce qui fait échouer une reprise
Les reprises que nous rattrapons ont presque toujours échoué pour l'une de ces raisons.
- L'import la veille. Découvert en dernière semaine, fait une seule fois, un vendredi soir.
- Tout reprendre. Dix ans d'historique importés avec leurs erreurs, au lieu de ce qui vit encore.
- Deviner. Un identifiant complété, une date supposée ; l'erreur se découvre au premier virement.
- Pas de règle sur les doublons. Fusionnés à la main, différemment par chaque personne.
- Pas de rapprochement. « Ça a l'air bon » ; le solde total n'a jamais été comparé.
- L'ancien système encore ouvert. Des saisies des deux côtés pendant la bascule.
- Pas de retour arrière. Lundi matin, il n'y a plus de chemin pour revenir.
Questions fréquentes
Les questions que nous recevons de gérants, de comptables et de fondateurs.
- Peut-on récupérer nos fichiers Excel dans la nouvelle application ?
- Oui, et c'est un chantier à part entière : inventaire des fichiers, table de correspondance colonne par colonne, nettoyage, trois chargements à blanc et un rapprochement des totaux. On reprend ce qui vit encore, clients, produits, soldes, stock, commandes ouvertes ; l'historique ancien reste consultable dans une archive plutôt que d'être importé avec ses erreurs.
- Que deviennent les doublons ?
- Ils sont détectés par une clé, le téléphone et l'identifiant, puis par une comparaison tolérante des noms, et fusionnés par une règle écrite ; quand la règle hésite, la liste est validée par le gérant. Les soldes s'additionnent, les lignes d'origine restent attachées à la fiche, et chaque fusion peut être défaite.
- Comment prouve-t-on que rien n’est perdu ?
- Par un rapprochement lu le samedi de la bascule : des totaux choisis avec votre comptable, nombre de clients actifs, factures ouvertes une par une, solde total au dinar près, stock par dépôt, égaux dans l'ancien système et dans le nouveau. Si un chiffre diffère, l'ouverture est repoussée ; ce n'est pas une impression, c'est une égalité.
- Pourquoi nos dates et nos numéros sont-ils faux dans l’export ?
- Parce que le tableur stocke les dates comme des nombres comptés depuis 1900 et ne garde que quinze chiffres de précision pour un nombre : 45123 est une date, et un identifiant de vingt chiffres saisi comme un nombre a perdu ses derniers chiffres. Les dates se convertissent avec la règle du tableur ; un chiffre perdu ne se retrouve pas, il se redemande.
- L’activité s’arrête-t-elle pendant la bascule ?
- Non, si elle est préparée : l'ancien système passe en lecture seule le vendredi soir, le chargement et le rapprochement se font le week-end, et la nouvelle application ouvre lundi matin. Un retour arrière reste possible jusqu'à une heure limite écrite à l'avance, et l'ancien système reste consultable ensuite.
- Combien de temps pour reprendre les données ?
- Six semaines, en parallèle de la construction de l'application : une pour l'inventaire et la correspondance, deux pour le nettoyage, deux pour les trois chargements à blanc, une pour la bascule et le suivi. La liste des valeurs à redemander part aux équipes dès la deuxième semaine, parce que c'est elle qui prend le plus de temps calendaire.