Faire correspondre les champs de deux logiciels avec l'IA

Faire correspondre les champs de deux logiciels consiste à définir, pour chaque donnée du système source, où elle doit atterrir dans le système cible et sous quelle forme. Ce n'est presque jamais un simple tableau à deux colonnes : un champ peut se découper en plusieurs champs de l'autre côté, une valeur peut être un code chez l'un et un libellé chez l'autre, et un champ obligatoire d'un côté peut tout simplement ne pas exister chez le second. C'est cette étape, sous-estimée dans la quasi-totalité des projets, qui fait exploser les délais d'un connecteur ou d'une migration de données.

Que le sujet soit une synchronisation continue entre deux logiciels ou une bascule ponctuelle vers un nouvel outil, le principe reste identique : sans mapping de champs propre et validé par le métier, la technique construit sur du sable. L'IA change la donne sur une partie précise de ce travail, la proposition de correspondances et la lecture de champs mal nommés ou en texte libre, mais elle ne remplace jamais la décision métier ni la validation humaine du résultat.

Cet article détaille les cinq types de transformation qu'on rencontre systématiquement, ce que l'IA apporte réellement, ce qu'elle ne fait pas, et pourquoi le document de mapping est le livrable qui a le plus de valeur dans tout le projet.

Un mapping de champs n'est jamais un simple tableau de correspondance

La première erreur, presque toujours commise en début de projet, est de croire que faire correspondre les champs de deux logiciels revient à aligner deux listes de colonnes : "nom_client" d'un côté, "customer_name" de l'autre, une flèche entre les deux, terminé. Dans la réalité, cette relation simple ne concerne qu'une minorité des champs à traiter.

Trois cas cassent systématiquement cette hypothèse de départ.

• Un champ se découpe en plusieurs champs de l'autre côté. Le CRM stocke l'adresse complète dans un seul champ texte, mais le logiciel de facturation exige quatre champs distincts : rue, code postal, ville, pays. Il faut alors analyser et découper la chaîne, avec ses exceptions (numéro d'appartement, complément d'adresse, pays absent).
• Une valeur est un code chez l'un et un libellé chez l'autre. Le statut d'un dossier vaut "3" côté ERP et "En attente de validation client" côté logiciel de reporting. Sans table de traduction de ces valeurs, la donnée transférée devient illisible ou, pire, faussement lisible avec un mauvais sens.
• Un champ obligatoire d'un côté peut être vide de l'autre. Le nouveau logiciel exige une civilité pour créer une fiche contact, alors que l'ancien système ne l'a jamais collectée. Ce vide bloque l'import tant que personne n'a tranché une règle : valeur par défaut, déduction depuis le prénom, ou saisie manuelle a posteriori.

Ces trois cas ne sont pas des exceptions rares qu'on découvre en fin de projet. Ils représentent, sur la majorité des projets de mapping que nous cadrons, une part significative des champs à traiter. Les anticiper dès le cadrage, plutôt que de les découvrir pendant les tests, change directement la durée et le coût du projet. C'est aussi ce qui distingue un connecteur standard d'un développement sur mesure : le premier gère mal ces cas particuliers.

Les cinq types de transformation qu'on rencontre à chaque projet

Sur l'ensemble des mappings que nous cadrons, cinq types de transformation reviennent systématiquement, dans des proportions qui varient selon les logiciels mais jamais dans leur nature.

• Renommage simple. Le champ existe des deux côtés, avec le même sens et le même format, seul le nom de la colonne change. C'est le cas le plus rare en pratique, même s'il reste celui auquel tout le monde pense en premier.
• Découpage ou fusion. Un champ source doit être scindé en plusieurs champs cibles (adresse complète vers rue, code postal, ville) ou, à l'inverse, plusieurs champs source doivent être fusionnés en un seul (prénom et nom vers un champ "nom complet").
• Conversion d'unité ou de format. Dates au format américain contre format français, montants hors taxes contre montants toutes taxes comprises avec un taux de TVA à appliquer, civilités abrégées ("M.", "Mme") contre civilités en toutes lettres. Ce type de transformation est purement mécanique une fois la règle posée, mais il faut la poser explicitement pour chaque champ concerné, pas seulement pour les plus visibles.
• Traduction de nomenclature. Les deux systèmes utilisent des listes de valeurs différentes pour décrire la même réalité : statuts de commande, catégories de produit, types de contrat. Il faut construire une table de correspondance de valeurs à part entière, distincte de la correspondance des champs eux-mêmes.
• Enrichissement. La donnée cible n'existe tout simplement pas dans le système source et doit être déduite ou calculée : une région déduite d'un code postal, une catégorie de client déduite d'un volume d'achat, un statut estimé à partir de la date de dernière activité.

Un projet de mapping réel combine presque toujours ces cinq types sur des champs différents d'un même flux. C'est cette combinaison, plus que le nombre brut de champs à traiter, qui détermine la complexité réelle du travail.

Ce sujet est directement lié à celui traité dans notre article sur supprimer la double saisie entre deux logiciels métier : une fois le mapping construit, il faut encore choisir dans quel sens et selon quel schéma la donnée doit circuler entre les deux outils.

Ce que l'IA apporte réellement au mapping de champs

Sur un mapping évident, deux champs au nom identique et au même format, un modèle de langage n'apporte rien qu'un tableau croisé ne fasse déjà. L'IA devient utile précisément là où la correspondance n'est pas écrite noir sur blanc dans les noms de colonnes, ce qui couvre la majorité des cas réels.

Quatre apports concrets reviennent sur ce type de projet.

• Proposer automatiquement les correspondances probables. En lisant les noms de champs et, surtout, des échantillons de valeurs réelles issues des deux systèmes, un modèle de langage propose un premier jeu de correspondances avec un niveau de confiance associé à chacune. Les champs à confiance élevée avancent vite, ceux à confiance faible sont signalés pour relecture prioritaire.
• Détecter un champ mal nommé à partir de son contenu. Un champ intitulé de façon opaque, par exemple "REF2" ou "CHAMP_LIBRE_3", peut en réalité contenir un numéro de TVA intracommunautaire ou une référence de contrat. En lisant les valeurs plutôt que le seul nom de colonne, l'IA repère ces cas que la seule lecture du schéma ne révèle jamais.
• Repérer les nomenclatures qui nécessitent une traduction. Quand deux listes de valeurs (statuts, catégories, types) décrivent la même réalité avec des libellés différents, l'IA propose la table de correspondance en analysant les occurrences réelles dans les deux bases, plutôt que de partir d'une documentation souvent obsolète.
• Extraire des données structurées depuis un champ commentaire fourre-tout. Un champ texte libre où un utilisateur a noté une date de relance, une consigne de livraison ou une référence, mélangés dans la même phrase, peut être décomposé pour alimenter les bons champs structurés du système cible.

Dans les quatre cas, le gain se mesure sur le temps de première proposition, pas sur la fiabilité finale : c'est la relecture métier qui transforme une proposition en règle de production fiable, jamais l'IA seule.

Ce que l'IA ne fait pas : les décisions qui restent humaines

Un mapping de champs contient toujours une part de décision qui n'a rien de technique. Ces décisions, personne ne les a écrites nulle part avant le projet, ce qui explique pourquoi aucun outil, IA comprise, ne peut les deviner correctement à tous les coups.

Deux catégories de décisions restent structurellement humaines.

• Les règles métier que personne n'a écrites. Faut-il arrondir un montant au centime supérieur ou inférieur ? Un client "inactif depuis 12 mois" doit-il devenir "prospect froid" ou rester "client" dans le nouveau système ? Ce sont des choix d'entreprise, pas des choix de format de données, et ils demandent l'arbitrage d'une personne qui connaît le métier.
• Ce qu'on fait des enregistrements sans équivalent. Une fiche du système source qui ne correspond à rien dans le système cible, une valeur de nomenclature qui n'a jamais été mappée : faut-il l'ignorer, la mettre en attente, ou créer une nouvelle catégorie dans le système cible ? Ce sont des décisions qui engagent l'entreprise sur la durée, pas des cas à trancher automatiquement au fil de l'eau.

C'est pour cette raison que la validation humaine du mapping reste obligatoire, quel que soit le niveau de confiance affiché par le modèle. Notre article sur où placer la validation humaine dans une automatisation détaille comment calibrer ce contrôle sans recréer le goulot d'étranglement qu'on cherchait justement à supprimer : sur un mapping, la validation porte sur les correspondances à confiance faible et sur les règles métier, pas sur chaque ligne de donnée transférée une fois le mapping approuvé.

Le document de mapping : le livrable qui a le plus de valeur

Le document de mapping n'est pas une formalité qu'on produit pour archiver le projet. C'est le livrable qui conditionne tout le reste, et c'est souvent l'étape la plus sous-évaluée en durée dans les plannings.

Il doit être relu et validé par le métier avant la première ligne de code. Pas après un premier développement, pas "en parallèle" du développement. Une correspondance de champ posée sur une hypothèse technique et jamais confrontée à la personne qui connaît réellement les données finit presque toujours par contenir une erreur découverte tardivement, souvent au moment le plus coûteux à corriger : une fois le connecteur en production.

Il sert ensuite de base directe aux tests. Chaque ligne du document de mapping devient un cas à vérifier lors de la recette : on prend un enregistrement réel, on suit sa transformation champ par champ, et on compare le résultat obtenu à la règle documentée. Sans document de mapping écrit, la recette se transforme en vérification approximative, "ça a l'air bon", qui laisse passer exactement les cas limites qu'on cherchait à couvrir.

C'est ce cadrage que nous menons dans le cadre de notre offre de connecteur sur mesure entre logiciels : lister les champs des deux systèmes avec des échantillons de valeurs réelles, produire un document de mapping soumis au métier, puis ne développer que ce qui a été validé.

Les champs libres et les commentaires, le piège classique

Le mapping le plus difficile à réussir ne porte jamais sur les champs structurés bien nommés. Il porte sur les champs libres et les commentaires, ceux qu'on écarte souvent du périmètre au premier passage parce qu'ils semblent secondaires.

C'est exactement l'inverse dans la pratique : c'est là que se cache la vraie information métier. Un commercial qui n'a pas de champ dédié pour noter une date de relance l'écrit dans le champ commentaire. Un technicien qui n'a pas de champ pour signaler une contrainte d'accès chantier la glisse dans les notes d'intervention. Ces informations existent, mais elles ne sont exploitables par aucun des deux systèmes tant qu'elles restent noyées dans du texte libre.

Traiter correctement ce cas suppose d'abord de reconnaître qu'un champ commentaire est souvent une donnée structurée mal rangée, pas une simple note accessoire. Notre article sur structurer des données non structurées avec l'IA détaille la méthode complète d'extraction et de contrôle sur ce type de champ, au-delà du seul cas du mapping entre deux logiciels.

Le niveau de confiance à accorder à cette extraction dépend directement de la régularité avec laquelle le champ a été rempli dans le temps. Plus les formulations varient d'un utilisateur à l'autre, plus il faut valider un échantillon représentatif avant de généraliser la règle d'extraction à l'ensemble de la base. Ce constat rejoint plus largement la question de la qualité des données disponibles avant tout projet impliquant de l'IA, que nous traitons dans données prêtes pour l'IA : ce qui compte vraiment. Ce cas précis, celui d'une migration qui doit reprendre cet historique de champs libres, fait l'objet d'un article dédié : reprendre un historique de champs libres avec l'IA.

Questions fréquentes sur la correspondance de champs entre deux logiciels

Pour aller plus loin

• Supprimer la double saisie entre deux logiciels métier : une fois le mapping construit, comment choisir le bon schéma de synchronisation entre les deux outils.
• Structurer des données non structurées avec l'IA : la méthode complète pour extraire une information exploitable d'un champ texte libre.
• Données prêtes pour l'IA : ce qui compte vraiment : évaluer la maturité de ses données avant tout projet impliquant de l'IA.
• Où placer la validation humaine dans une automatisation : calibrer le contrôle humain sans recréer un goulot d'étranglement.
• Synchroniser deux logiciels sans identifiant commun : le cas où même les champs bien mappés ne suffisent pas à relier les deux fiches.
• Le coût d'un connecteur sur mesure entre logiciels : comment ce travail de mapping pèse dans le chiffrage global.