Migrer depuis Assur3D : ce que vous gardez, ce que vous perdez, ce qu’on vous demande de trancher

La reprise se fait en deux temps, et dans cet ordre : d’abord les clients, ensuite les contrats. Ce n’est pas une préférence de méthode, c’est une contrainte de fond — un contrat doit se rattacher à une fiche qui existe déjà, sinon il se rattache à une ressemblance de nom.

L’export de contrats d’Assur3D porte l’identifiant du client que le même Assur3D a écrit dans l’export de clients. Quand les deux passages ont eu lieu, le rattachement d’un contrat cesse d’être une ressemblance de libellé pour devenir une égalité d’identifiant. C’est toute la différence entre une reprise qu’il faut relire et une reprise qui tient.

Vous n’avez pas à déclarer de quel logiciel vient le fichier : le format est reconnu à l’ouverture. Et si vous déposez l’export de clients sur l’écran des contrats — ils se ressemblent — l’écran vous le dit et vous renvoie au bon endroit, au lieu de répondre « fichier illisible ».

• Les fiches clients : identité, civilité, adresse complète, téléphones, adresses e-mail (y compris secondaires), date de naissance, profession, et pour les entreprises la raison sociale, le SIRET, le SIREN et le code d’activité.
• Les contrats : numéro de police, risque, compagnie, produit, date d’effet, dernière échéance connue, dernière prime TTC et HT, dernière commission, état actif ou résilié, et date de résiliation le cas échéant.
• L’identifiant d’origine de chaque fiche, conservé : c’est lui qui rend l’import rejouable et qui relie ensuite les contrats à leur client.
• Les réparations mineures signalées et comptées : un téléphone dont les zéros ont été mangés par un tableur, un code postal amputé. Elles sont corrigées, et le compte rendu dit combien l’ont été.

• Les coordonnées bancaires. La lecture note qu’une ligne en portait une, et n’en garde pas la valeur. Un IBAN n’a rien à faire dans un fichier de reprise qui transite entre deux outils.
• Les prospects et les anciens clients, par défaut. Être présent dans un fichier ne fait pas entrer quelqu’un dans un portefeuille. Ils sont écartés, nommés dans le compte rendu, et vous pouvez demander explicitement de les reprendre — ils arrivent alors étiquetés comme tels.
• Les sinistres. Une feuille de sinistres est reconnue et écartée de l’import de contrats, avec son nombre de dossiers : elle relève d’un autre périmètre.
• Les pièces et documents. Ils ne figurent pas dans les exports d’Assur3D. Ils se reprennent séparément, par dépôt dans la gestion documentaire.
• La prochaine échéance. Le fichier donne la dernière échéance connue : elle est reprise pour information, jamais transformée en échéance à venir. Une date déduite qui déclenche une relance est pire qu’une date absente.

C’est le cœur de cette page, et ce qui explique qu’une reprise demande un peu de votre temps plutôt qu’aucun. Trois refus assumés :

Rattacher un client incertain. Le rapprochement rend un verdict, jamais une décision : sûr quand une seule fiche est possible sans lecture concurrente, incertain quand plusieurs candidats existent ou qu’un doute est nommé, inconnu quand aucun candidat n’est plausible. Un lot ne peut contenir que des lignes sûres : dès qu’une ligne incertaine s’y trouve, tout le lot est refusé et rien n’est écrit. Une ligne incertaine s’écrit ensuite seule, après votre arbitrage.

Écraser un contrat existant. Si un contrat identique est déjà en base, il est laissé tel quel et nommé dans le compte rendu. Un import de reprise n’a aucune raison de recouvrir ce qu’un courtier a saisi à la main.

Trancher une collision. Deux lignes d’un même fichier peuvent porter le même client, le même numéro de police, la même date d’effet et le même produit, avec des montants différents. Aucune règle ne dit laquelle fait foi. Elles sont nommées et remontées à l’écran ; jamais l’une n’écrase l’autre.

Même logique sur les colonnes : les en-têtes sont reconnues nommément, et un fichier incomplet est refusé en disant ce qui manque. Mal deviner les colonnes d’un portefeuille est plus grave que refuser de l’importer.

Si une fiche est créée alors qu’un homonyme existe déjà dans le CRM, elle est créée et signalée : le compte rendu la nomme comme doublon possible. L’import n’archive jamais une fiche existante — une fiche saisie à la main par le cabinet ne peut pas disparaître parce qu’un fichier a été déposé.

Cette règle vient d’un incident réel, et nous préférons la raconter : une fiche saisie à la main portait un nom sans accent, le fichier l’écrivait avec. La comparaison de noms, insensible à la casse mais pas aux accents, ne les a jamais reconnus comme identiques — le jumeau a été créé sans un mot. Depuis, un homonyme à l’accent près est nommé, et la fusion reste une décision humaine.

Chaque écriture produit un compte rendu conservé, consultable après coup. Il porte le nom du fichier déposé, son empreinte, la table ou la feuille choisie, le mode d’écriture, qui a lancé l’import, le nombre de lignes lues, celles qui ont écrit en base, celles qui ne l’ont pas fait — et le détail ligne par ligne, chaque refus avec son motif.

C’est la ligne qui compte le plus : toute ligne du fichier qui n’est pas entrée en base est nommée. Sans elle, un import qui reprend la moitié d’un portefeuille ne laisse aucune trace de l’autre moitié — et la moitié manquante ne se découvre que des mois plus tard, quand un client appelle.

Le compte rendu distingue aussi ce que la lecture n’a pas pu établir et l’affiche avant les compteurs. Un écran qui ne montre que des totaux se lit comme une certitude.

Beaucoup de cabinets ont, en plus de l’export, un classeur maison qui a servi de béquille pendant des années. Il est accepté lui aussi. L’analyse liste alors toutes les feuilles qui ressemblent à de la production, avec pour chacune le nombre de lignes exploitables, la période couverte, la prime et la commission cumulées — et n’en présélectionne aucune.

Quand plusieurs feuilles décrivent visiblement le même portefeuille avec des montants différents, un avertissement le dit en toutes lettres, chiffres à l’appui. Ce sont des révisions successives : les importer toutes multiplierait le portefeuille, et en choisir une « au plus récent » trancherait à la place du cabinet.

Éléments relevés dans la version en production d’ACTUAL DATA le 7 septembre 2026. Nous ne publions pas de durée type de migration : elle dépend de la qualité de l’export de départ et du nombre d’arbitrages, et un délai annoncé sans les connaître ne voudrait rien dire. La méthode générale d’un changement d’outil — ordre des étapes, garanties à exiger par écrit — est détaillée dans notre article sur la migration.

Assur3D est un éditeur français établi, cité dans les comparatifs du secteur depuis des années, et cette page n’est pas un procès. Si vous en partez, c’est votre décision — la nôtre est de faire en sorte qu’elle ne vous coûte pas votre portefeuille. Deux faits, à leur crédit, méritent d’être dits : leur offre inclut l’import et l’export des portefeuilles clients et contrats dès le premier pack, et c’est précisément ce qui rend cette page possible ; et leur grille tarifaire est publiée, ce qui n’est pas si courant — 39,90 € HT par utilisateur et par mois pour les courtiers de moins de deux ans, 59,90 € puis 79,90 € HT par utilisateur pour les deux autres packs, relevés sur assur3d.com le 7 septembre 2026.

Une différence de structure mérite d’être notée, parce qu’elle change le calcul à plusieurs collaborateurs : leur tarif est affiché par utilisateur, quand le nôtre inclut un nombre d’utilisateurs par offre. Comparez donc à effectif réel, pas au prix d’entrée.