La configuration dans la base, pas dans le code

Posons d'emblée une thèse réfutable : dans une intégration, seuls les connecteurs méritent du code. Les correspondances entre champs — quel champ source alimente quel champ cible, avec quelle transformation — sont des données métier. Leur place est dans une base, pas dans un fichier source. Si renommer un champ ou brancher une source exige un déploiement, c'est que de la donnée s'est glissée dans le code.

L'arithmétique plaide déjà dans ce sens. Relier n applications deux à deux exige jusqu'à n(n−1) traducteurs de données ; introduire un modèle de données pivot ramène ce nombre à 2n. Pour six applications, c'est 30 contre 12 — l'exemple vient du livre de référence Enterprise Integration Patterns (pattern Canonical Data Model).

Le modèle pivot règle la combinatoire ; la séparation code/données règle l'entretien. Un connecteur s'écrit une fois par grammaire d'API, puis se stabilise. Les correspondances, elles, évoluent en continu : nouveaux champs, nouvelles valeurs, nouvelles sources. Et le contexte aggrave la facture : l'entreprise moyenne déploie 101 applications, selon l'étude Businesses at Work 2025, commanditée et publiée par Okta. Personne ne maintiendra jamais l'écheveau point-à-point d'un parc pareil.

L'objection classique vient du manifeste twelve-factor : « séparation stricte de la configuration et du code », donc variables d'environnement. Mais le twelve-factor parle de configuration de déploiement — credentials, URL de services, ressources — c'est-à-dire ce qui varie d'un déploiement à l'autre. Un mapping de champs ne varie pas entre les déploiements : il varie avec le métier.

Le Google SRE Workbook place la question au bon niveau :

« La configuration est une interface humain-machine pour modifier le comportement d'un système. » — The Site Reliability Workbook, chap. 14 (traduction libre)

Le même chapitre pose qu'avoir du code et des données, mais en les séparant, est l'optimum — et recommande de formuler les options de configuration en termes d'objectifs métier plutôt qu'en détails d'implémentation. C'est précisément ce que fait une table de mapping : elle pose des questions de connaisseur des données — l'email professionnel de la source A alimente-t-il le champ email du référentiel ? — jamais des questions de code (endpoints, pagination, authentification). C'est ce qui rend l'intégration pilotée par la configuration (configuration-driven integration) extensible par des non-développeurs : le périmètre de ce qu'ils éditent est étroit, déclaratif, lisible.

Nous opérons ce pattern en production pour consolider des systèmes hétérogènes. Un moteur de synchronisation écrit en Python, orchestré sur Trigger.dev, lit sa configuration dans une base Airtable et relie six CRM et ERP vers un référentiel unique — dont un CRM SaaS à propriétés personnalisées (HubSpot), un ERP dont l'API implémente OData 4.0, standard OASIS (Dynamics 365), et une application métier legacy qui expose une API SOAP/XML. Trois grammaires d'API ; une seule table de correspondances. Synchroniser plusieurs CRM revient alors à ajouter des lignes de mapping, pas du code. Côté équipes : zéro re-saisie manuelle.

Chaque ligne de la table est un Message Translator — l'autre pattern fondateur de Hohpe & Woolf — déclaré en données plutôt que codé :

{
  "systeme_source": "crm_a",
  "champ_source": "email_pro",
  "transformation": "minuscules, espaces supprimés",
  "entite_cible": "personne",
  "champ_cible": "email",
  "cle_rapprochement": "email",
  "sens": "source vers référentiel",
  "actif": true
}

En termes ETL — extraire, transformer, charger vers un magasin unifié, selon la définition de Microsoft — les connecteurs extraient, la table déclare les transformations, le moteur charge le référentiel. L'orchestrateur apporte ce qu'un script planifié n'offre pas : files d'attente, retries automatiques, monitoring temps réel (Trigger.dev se présente comme un framework open source de background jobs). Nous avons documenté les critères qui justifient ce niveau d'outillage dans quand industrialiser une automatisation.

Un détail de conception honnête : l'API Web d'Airtable applique une limite documentée de 5 requêtes par seconde et par base. La configuration se lit donc en début de run et se met en cache — jamais à chaque enregistrement. Une couche de configuration se consulte rarement et s'édite souvent : c'est exactement le profil d'usage d'une base.

Stocker des règles métier dans des tables peut sembler artisanal. C'est l'inverse. DMN (Decision Model and Notation), norme publiée par l'Object Management Group, existe précisément pour spécifier des décisions métier « dans des tables de décision non ambiguës », lisibles par les métiers. Côté recherche, Rahm & Bernstein ont établi dès 2001 que la mise en correspondance de schémas est un problème fondamental de l'intégration de données, « typiquement réalisée manuellement ». La table de mapping ne supprime pas ce travail : elle le rend explicite, versionnable et relisible, au lieu de le disperser dans du code.

La différence avec un moteur de règles générique tient au périmètre :

• pas de chaînage implicite entre règles ;
• pas de langage d'expression complet ;
• un mapping plat — source, transformation, cible — exécuté par un orchestrateur observable.

Les utilisateurs mappent, ils ne programment pas. C'est ce périmètre étroit qui tient la promesse « extensible par des non-développeurs », là où des périmètres trop larges la fragilisent.

C'est aussi ainsi que les systèmes anciens redeviennent des sources de plein droit : SOAP 1.2 est une Recommandation W3C de 2003, toujours parlée par des applications en production. Le connecteur absorbe la grammaire ; la table ne voit que des champs. Même mouvement que moderniser un ERP legacy sans le remplacer : on entoure l'existant, on ne le réécrit pas.

Ce que ça coûte de ne rien faire — Chaque intégration point-à-point ajoutée aujourd'hui est une dette combinatoire : à six systèmes, l'écheveau complet représente jusqu'à 30 traducteurs à maintenir, et le septième peut en ajouter 12 d'un coup (Hohpe & Woolf). Pendant ce temps, le parc moyen atteint 101 applications (Okta, 2025). Et chaque correspondance codée en dur mobilise un développeur, un déploiement et un test de non-régression — parfois pour renommer un seul champ.

Voici la structure anonymisée de notre table de mapping — celle qui pilote la synchronisation par mapping (mapping-driven sync) de nos six sources vers le référentiel. Elle tient en neuf champs.

Trois opérations du quotidien deviennent des éditions de table : brancher une source (ajouter des lignes), corriger une correspondance (modifier une ligne), suspendre un flux douteux (désactiver une ligne). Les évolutions courantes passent d'une revue de code à une revue de table. Cette séparation nette entre un moteur stable et une configuration vivante est un principe constant de notre façon de construire.

Les connecteurs restent du code : une nouvelle grammaire d'API (SOAP, OData, REST propriétaire) demande un travail de développeur. Une table plate n'exprime pas tout : logique conditionnelle riche, dédoublonnage approximatif, orchestration multi-étapes vivent dans le moteur, pas dans la configuration. La configuration devient elle-même un actif de production : sans historique des modifications, droits d'édition maîtrisés et jeu d'essai, on déplace le risque au lieu de le réduire. Enfin, le pattern a un coût d'entrée : sous deux ou trois systèmes stables, un script direct reste souvent le bon choix — c'est précisément ce que nos critères d'industrialisation aident à trancher.