Couche data commune pour agents IA : l'architecture pivot

Vous avez déployé un premier agent. Ça marche. Vous commencez un deuxième chantier. Puis un troisième. Et là, le problème commence : chaque nouveau cas d’usage reconstruit les mêmes entités depuis zéro. Trois agents qui manipulent «client», trois représentations différentes du même objet, trois dettes d’intégration qui s’accumulent.

Ce n’est pas un problème d’agents. C’est un problème d’architecture data.

TL;DR : Quand trois cas d’usage IA ou plus ont besoin du même référentiel, construire une couche data commune est moins cher que trois projets silos. Le signal est le nombre de chantiers qui partagent les mêmes entités. L’architecture repose sur deux règles : entités mutables centralisées, activités immuables loguées. Le pipeline Bronze/Silver/Gold structure la progression sans migration totale.

Pourquoi trois chantiers IA coûtent plus que trois fois un chantier

Le premier chantier IA coûte ce qu’il coûte. Le deuxième repart d’une ardoise presque vierge. Le troisième aussi. À chaque nouveau cas d’usage, on cartographie les sources de données, on nettoie les doublons, on harmonise les identifiants. Ce travail se refait intégralement - même si les entités manipulées sont les mêmes.

Pour une PME qui accompagne plusieurs dizaines de projets IA chaque année, j’observe que 60 à 70 % du temps d’un projet consiste à localiser et préparer la donnée avant de pouvoir l’exploiter. Ce coût est incompressible sur un chantier isolé. Sur une couche commune, il s’amortit sur l’ensemble des chantiers suivants.

Le signal concret pour passer à l’architecture commune : quand trois chantiers ou plus ont besoin du même référentiel (clients, fournisseurs, produits), construire chaque chantier séparément revient à créer les mêmes entités autant de fois. La dette s’accumule. La couche commune est plus chère en V1, moins chère à partir du troisième chantier.

Selon McKinsey (State of AI 2025), les entreprises qui refondent leur architecture data avant de déployer l’IA voient un impact mesurable. Celles qui superposent l’IA sur des silos voient peu ou pas de changement. L’écart n’est pas dans les modèles. Il est dans les fondations.

L’Entity-Centric Activity Graph : la distinction qui structure tout

Avant de modéliser quoi que ce soit, une clarification s’impose. Dans une couche data agentique, deux types d’objets coexistent et n’obéissent pas aux mêmes règles.

Les entités sont mutables. Un client change d’adresse, un produit change de prix, un fournisseur change de conditions de paiement. Ces objets s’upsertent : on met à jour l’enregistrement existant sans créer de doublon.

Les activités sont immuables. Une commande passée, une validation signée, une réunion tenue, une analyse produite ne s’éditent pas. Elles s’ajoutent. Une commande annulée ne supprime pas la commande d’origine - elle crée un événement «annulation» avec sa propre date. Ce principe - que les architectes data nomment parfois Entity-Centric Activity Graph - a trois effets immédiats.

Premier effet : les jointures naturelles entre entités et activités donnent les vues métier sans transformation complexe. Vous voulez la liste des commandes d’un client sur les 6 derniers mois ? C’est une jointure directe entre la table entités-clients et la table activités-commandes. Aucun outil de reporting tiers requis.

Deuxième effet : les conflits de données disparaissent. On n’écrase plus des états passés. La question «quelle était la valeur de ce champ en mars ?» trouve toujours une réponse dans les activités.

Troisième effet : un audit trail se construit naturellement. Chaque action laisse une trace sans effort supplémentaire. Pour vos agents IA, c’est un historique sur lequel raisonner. Pour vous, c’est une traçabilité qui facilite la détection d’anomalies.

Cette distinction vaut pour n’importe quelle base - Notion, Airtable, Supabase, PostgreSQL. Elle ne dépend pas de l’outil. Elle dépend de la discipline de modélisation.

Réutiliser avant de reconstruire

Un raccourci souvent négligé : avant de créer une nouvelle table pour un nouveau chantier, vérifier si une table existante peut accueillir les données avec un champ supplémentaire.

Une table contenus qui accueille à la fois les pages d’un site web et les fiches produit, avec un champ platform = 'site' ou platform = 'catalogue', permet de croiser trafic analytics et données produit dans la même requête. C’est souvent le raccourci le plus rapide avant une refonte complète - et ça évite de créer un nouveau silo.

La règle : les jointures cross-domaine deviennent possibles sans ETL custom dès que les identifiants de liaison sont documentés et les données dans la même base. Un seul identifiant client partagé entre votre CRM, votre outil de facturation et votre support suffit pour relier trois sources sans migration.

J’ai détaillé les prérequis d’un premier déploiement d’agents dans cet article sur les données IA avant vos agents. Ce qui suit va plus loin : l’architecture pour plusieurs chantiers simultanés.

Le pipeline Bronze / Silver / Gold : structurer la progression

Quand les données arrivent de sources multiples - CRM, ERP, formulaires, analytics, outils métier - un pipeline en trois niveaux structure la progression sans tout migrer d’un coup.

Bronze : la donnée brute, ingérée sans transformation depuis les sources existantes. Exports CRM, logs ERP, historiques emails. Tout rentre tel quel. Airbyte, avec ses 300+ connecteurs natifs vers Supabase et les principales bases de données, automatise cette couche sans code custom pour les sources standard. Chaque intégration réalisée est une source de Bronze immédiatement requêtable.

Silver : la donnée structurée et joignable. Les entités sont normalisées et dédupliquées. Un client qui existe dans trois outils différents est réconcilié en un seul enregistrement avec un identifiant unique. Les identifiants de liaison sont documentés. C’est à ce niveau que la distinction entités/activités est appliquée, et que vos agents peuvent raisonner cross-sources sans jongler entre interfaces.

Gold : la donnée interprétée, taguée, prête pour les agents en production. Les colonnes ont des définitions métier claires. Les anomalies sont flagguées. Les métriques calculées. Ce niveau s’enrichit à mesure que vos agents produisent de l’output et révèlent ce dont ils ont besoin.

Ce pipeline clarifie les responsabilités : les outils d’ingestion gèrent le Bronze, le travail d’architecture gère le Silver, les agents opèrent sur le Gold. La couche Gold n’est pas un état final - c’est un flux. Chaque nouveau chantier révèle des gaps dans le Silver qui remontent vers le Bronze pour être comblés. C’est la séquence correcte, pas un signe d’inachèvement.

Pour une PME de 30 à 50 salariés, modéliser correctement les entités du premier chantier prend environ un mois. L’erreur fréquente est de vouloir tout modéliser avant de déployer la première action. Mieux vaut modéliser les entités du premier chantier, déployer, et laisser les chantiers suivants révéler les gaps de modélisation.

Quelle architecture pour quelle taille de PME ?

Pour 10 à 30 salariés, Airtable ou Notion suffisent en V1. L’important n’est pas la puissance de l’outil - c’est la discipline de désignation : une base pour les entités, une table pour les activités, des vues en lecture sur les autres outils. Quand la couche est validée sur un premier chantier, migrer vers une base plus robuste est une décision technique, pas une urgence.

Pour 30 à 100 salariés avec plusieurs équipes et plusieurs flux de données, une base SQL hébergée (Supabase ou PostgreSQL) change le rapport au coût d’intégration. Les jointures cross-domaine deviennent possibles sans ETL custom : trafic site, leads CRM et commandes ERP dans la même requête. C’est à ce niveau que les agents commencent à produire des analyses que vos équipes ne pouvaient pas faire manuellement, faute de temps et d’outils adaptés.

Au-delà de 100 salariés, la question n’est plus l’architecture technique. C’est la gouvernance : qui décide de l’ontologie, qui valide les nouveaux champs, qui gère les conflits entre équipes quand deux chantiers ont des définitions différentes d’un même objet. Cette gouvernance doit être en place avant de déployer des agents en production.

Quel que soit le niveau, la séquence reste identique : identifier les entités du premier chantier, les centraliser, déployer le premier agent, mesurer les gaps révélés. La couche data se construit par itérations ancrées dans des cas d’usage réels, pas par une modélisation exhaustive en chambre.

Pour comprendre comment ce travail de décomposition s’applique concrètement à l’automatisation de processus métier, la méthode des actions atomiques donne le cadre opérationnel qui suit naturellement.

La séquence non-négociable

Alex Hormozi formule la séquence nettement dans son positionnement de 2025 : centraliser la donnée d’abord, construire la couche IA ensuite. Cette séquence n’est pas un frein au déploiement - c’est ce qui rend le déploiement durable.

Les organisations qui déploient des agents avant d’avoir résolu la couche data paient deux fois : une fois pour construire l’agent, une deuxième fois pour le reconstruire quand les données sont finalement structurées. C’est une dette d’intégration qui ne se rembourse qu’en refaisant le travail.

La couche data commune est plus chère à construire en V1 qu’un chantier isolé. Elle est moins chère à maintenir à partir du troisième chantier. Le point de bascule se situe là. Selon Bpifrance Le Lab (étude IA dans les PME et ETI, 2025), 58 % des dirigeants français considèrent l’IA comme un enjeu de survie à moyen terme. La couche data est le travail de fond qui rend cet enjeu traitable.

---

FAQ

Quand faut-il construire une couche data commune plutôt que des silos par chantier ?

Quand trois chantiers ou plus partagent les mêmes entités de base (clients, produits, fournisseurs). En dessous de ce seuil, un silo par chantier est souvent plus rapide. Au-delà, la dette d’intégration dépasse le coût de construction de la couche commune.

Peut-on construire la couche commune après avoir démarré plusieurs chantiers silos ?

Oui, mais c’est plus coûteux. La séquence recommandée est de partir des entités communes identifiées dans les silos existants et de les consolider progressivement. On ne refait pas tout - on désigne une surface autoritaire pour chaque entité et on migrate les autres en vues en lecture.

Quelle est la différence entre couche data commune et data warehouse ?

Un data warehouse est conçu pour l’analyse et le reporting, souvent en lecture seule. Une couche data commune pour agents IA est aussi en écriture : les agents loguent leurs activités, mettent à jour des entités, enrichissent des enregistrements. C’est un objet vivant, pas un entrepôt statique.

Combien de temps pour construire la couche commune en PME de 30 à 50 personnes ?

Entre deux et six semaines pour la V1 : identification des entités communes, séparation entités/activités, mise en place des identifiants de liaison, premier pipeline Bronze. La couche Gold s’enrichit au fil des chantiers. L’erreur est de vouloir construire la couche Gold avant de déployer le premier agent.

L’architecture entités/activités s’applique-t-elle à tous les secteurs ?

Oui. Une commande dans l’industrie, une réservation dans l’hôtellerie, une demande de support dans les services - tous ces objets sont des activités immuables attachées à des entités mutables (clients, produits, espaces). La terminologie change. La structure ne change pas.